Mon blog

Je suis Charlie

Autres trucs

Accueil

Seulement les RFC

Seulement les fiches de lecture

Mon livre « Cyberstructure »

Ève

Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.

RFC 9727: api-catalog: A Well-Known URI and Link Relation to Help Discovery of APIs

Date de publication du RFC : Juin 2025
Auteur(s) du RFC : K. Smith (Vodafone)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF httpapi
Première rédaction de cet article le 14 juin 2025

Les API réseau, c'est très bien. Tout le monde en fait aujourd'hui, typiquement bâties au-dessus de HTTP. Mais il est parfois difficile de s'y retrouver parmi toutes les API. « Je suis sûr que l'INSEE avait une API pour faire ça mais où est-elle exactement et où est sa documentation ? La solution pour cela ? Les catalogues d'API, rassemblant nom, description, URL, etc, des API. Il ne reste plus qu'à trouver le catalogue… Ce RFC fournit pour cela un URL standard et un mécanisme de lien. Il fournit également un format standard pour écrire ce catalogue, bâti sur Linkset (RFC 9264, section 4.2).

Comme disait M. de la Palice, et comme le rappelle la section 1 du RFC, pour utiliser une API, il faut d'abord la découvrir. Cela veut dire apprendre son existence, quel va être l'URL à appeler (le endpoint), les paramètres à passer, quelles sont les conditions d'utilisation (gratuite ? nombre maximal de requêtes par jour ?), etc. Il existe des formats pour cela (le plus connu étant celui d'OpenAPI) mais il reste à trouver les fichiers de ce format. Pour faciliter cette tâche du développeur ou de la développeuse qui utilisera l'API, l'éditeur (publisher dans le RFC) qui publie l'API va fabriquer un joli catalogue, et le rendre lui-même découvrable. Un catalogue est une liste organisée des API offertes par une organisation donnée.

Première solution décrite par notre RFC (section 2) : un URL bien connu, et donc prévisible, https://www.example.net/.well-known/api-catalog (si l'éditeur est en www.example.net). Ces URL bien connus sont normalisés dans le RFC 8615. Évidemment, une redirection HTTP est possible. api-catalog a été ajouté au registre des URL bien connus.

Deuxième solution, un lien (section 3) api-catalog. Les liens, vous connaissez, et ils sont normalisés dans le RFC 8288. Ils peuvent se représenter de plusieurs façons, en HTML : 


<!DOCTYPE HTML>
<html>
   <head>
         <title>Welcome to Example Publisher</title>
   </head>
   <body>
         <p>
          <a href="my_api_catalog.json" rel="api-catalog">
           Example Publisher's APIs
          </a>
         </p>
         <p>(remainder of content)</p>
   </body>
</html>

Ou bien en HTTP, dans la réponse : 


HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Location: /index.html
Link: </my_api_catalog.json>; rel=api-catalog
Content-Length: 356

Désormais, api-catalog figure dans le registre des types de liens.

Cette norme concerne la découverte du catalogue, mais aussi la syntaxe de son contenu. La section 4 du RFC donne des indications sur le contenu du catalogue, sa sémantique (inclure la politique d'utilisation, lien vers une spécification formelle, etc) et sa syntaxe, le format Linkset du RFC 9264. Des exemples figurent dans l'annexe A du RFC mais vous pouvez aussi regarder le le catalogue des mes API (en construction). Voici le premier exemple de catalogue donné dans le RFC, utilisant les relations du RFC 8631 : 

{
    "linkset": [
    {
      "anchor": "https://developer.example.com/apis/foo_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/foo_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/foo_api/doc",
          "type": "text/html"
        }
      ],
      "service-meta": [
        {
          "href": "https://developer.example.com/apis/foo_api/policies",
          "type": "text/xml"
        }
      ]
    },
    {
      "anchor": "https://developer.example.com/apis/bar_api",
      "service-desc": [
        {
          "href": "https://developer.example.com/apis/bar_api/spec",
          "type": "application/yaml"
        }
      ],
      "service-doc": [
        {
          "href": "https://developer.example.com/apis/bar_api/doc",
          "type": "text/plain"
        }
      ]
    }
  ]
}

D'autres formats que Linkset sont possible (mais Linkset doit être présent), par exemple via la négociation de contenu. Quelques formats possibles cités par le RFC :

Ce catalogue peut, et ce serait souhaitable, être écrit automatiquement par le cadriciel qu'on utilise pour développer ses API.

Et, sinon, où est-ce qu'on publie cette API ? La méthode recommandée (section 5) est de la publier à plusieurs endroits. Si on gère www.example.net et que les URL des API sont en api.example.com, le RFC recommande de les publier aux deux endroits. Rappelez-vous que les redirections HTTP sont permises, donc vous pouvez n'avoir qu'un seul exemplaire du catalogue, ce qui simplifie sa maintenance. Car, puisqu'on parle de maintenance, un gros défi sera clairement de garder ce catalogue à jour au fur et à mesure de l'évolution des API… (La section 8, sur la sécurité, revient sur ce problème.)

Je n'ai pas trouvé d'exemple réel dans le Web, même chez Vodafone, où travaille l'auteur. Mais j'ai fait un catalogue pour mes propres API. En l'absence d'outils de test et de validation pour les catalogues, il a peut-être quelques erreurs. (Si vous lisez la section 2 du RFC, vous verrez que mon serveur HTTP ne répond pas aux requêtes HEAD avec un lien dans l'en-tête, un Link:. Il devrait.)

Téléchargez le RFC 9727


L'article seul

RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes

Date de publication du RFC : Juin 2025
Auteur(s) du RFC : F. Driscoll, M. Parsons (UK National Cyber Security Centre), B. Hale (Naval Postgraduate School)
Pour information
Réalisé dans le cadre du groupe de travail IETF pquip
Première rédaction de cet article le 14 juin 2025

La cryptographie post-quantique vise à développer des algorithmes de cryptographie qui résistent à des ordinateurs quantiques. Mais ces algorithmes sont relativement récents et peuvent avoir des faiblesses, voire des failles, que la cryptanalyse classique pourra exploiter. La tendance actuelle est donc aux protocoles et formats hybrides, combinant algorithmes classiques et post-quantiques. Ce RFC spécifie la terminologie de ces protocoles hybrides.

On peut aussi dire AQ, pour après-quantique car le sigle anglophone PQ de post-quantum peut faire drôle en France. D'ailleurs, les termes à utiliser (post-quantique ? résistant au quantique ?) ont fait l'objet de chaudes discussions dans le groupe de travail IETF.

Le point de départ de tout le tintouin autour de l'après-quantique, c'est l'algorithme de Shor. Conçu pour les calculateurs quantiques, et donc inutilisable encore aujourd'hui, il permet de résoudre des problèmes mathématiques qu'on croyait difficiles, comme la décomposition en facteurs premiers (qui est derrière RSA) ou le logarithme discret (qui est derrière ECDSA). Le jour, qui n'est pas encore arrivé, où on aura des CRQC (Cryptographically-Relevant Quantum Computer, un calculateur quantique qui puisse s'attaquer à des problèmes de taille réelle, et pas juste faire des démonstrations), ce jour-là, la cryptographie classique, ou traditionnelle, aura un problème.

Les CRQC sont loin dans le futur, un lointain dont il est très difficile d'estimer la distance. Comme on ne sait pas quand est-ce que les CRQC seront disponibles, et que certains secrets qu'on chiffre maintenant devront rester secrets pendant de nombreuses années, il est prudent de travailler dès maintenant aux algorithmes AQ, après-quantique, ceux pour lesquels on ne connait pas d'algorithme (quantique ou classique) pour les casser. Ce travail a effectivement commencé depuis des années et on a déjà des algorithmes AQ normalisés comme ML-KEM (ex-Kyber). Notez toutefois qu'aucune norme IETF n'a encore été publiée en intégrant ces algorithmes, mais le travail est en cours, entre autre au sein du groupe de travail pquip.

Mais remplacer complètement les algorithmes traditionnels par les algorithmes AQ n'est pas forcément satisfaisant. Au contraire de RSA et ECDSA, testés au feu depuis longtemps et qui ont toujours résisté, les algorithmes AQ peuvent sembler un peu jeunes. Que se passerait-il si un·e cryptanalyste cassait un de ces algorithmes ? Pour limiter les dégâts, on envisage d'utiliser des mécanismes hybrides, combinant cryptographie classique (pré-quantique) et après-quantique. Ainsi, un chiffrement hybride verrait le texte en clair chiffré par un mécanisme classique puis par un mécanisme après-quantique. Une signature hybride se ferait en mettant deux signatures et en vérifiant ensuite que les deux sont valides. Cette méthode « ceinture et bretelles » est utilisée par exemple dans le RFC 9370 ou dans les Internet-Drafts draft-ietf-tls-hybrid-design, draft-ietf-lamps-pq-composite-kem ou draft-ietf-lamps-cert-binding-for-multi-auth. On peut aussi consulter la FAQ du NIST (« A hybrid key-establishment mode is defined here to be a key establishment scheme that is a combination of two or more components that are themselves cryptographic key-establishment schemes. ») ou bien le document ETSI TS 103 744 nommé « Quantum-safe Hybrid Key Exchanges ». Attention toutefois avec cette terminologie car l'adjectif « hybride » est également souvent utilisé en cryptographie pour désigner la combinaison d'un algorithme de cryptographie asymétrique avec un algorithme de cryptographie symétrique (quand on crée une clé de session échangée via de la cryptographie asymétrique puis qu'on chiffre les données avec cette clé et de la cryptographie symétrique ; c'est ce que font TLS et OpenPGP, par exemple). C'est le sens qu'utilisent les RFC 4949 et RFC 9180, par exemple. Notre RFC 9794 note que ces deux usages du terme « hybride » vont certainement prêter à confusion mais qu'il n'y avait pas trop le choix : chaque usage était déjà solidement installé dans un milieu particulier. Essayer de promouvoir un autre terme pour la cryptographie après-quantique, comme « double algorithme » ou « multi algorithme » était sans doute voué à l'échec.

Passons maintenant aux définitions. Je ne vais pas les reprendre toutes mais donner quelques exemples. La section 2 du RFC commence par les mécanismes de base et d'abord, mécanisme hybride traditionnel / post-quantique (post-quantum traditional hybrid scheme, ou PQ/T), un mécanisme qui combine la cryptographie existante et celle du futur. On peut aussi simplifier en disant juste mécanisme hybride. Il y a aussi :

  • Multi-algorithme, qui est plus large qu'hybride puisqu'il inclut les mécanisme ayant deux algorithmes traditionnels ou deux algorithmes après-quantique.
  • Composé (composite), qui désigne les mécanismes hybrides où le mécanisme est exposé aux couches supérieures sous forme d'une interface unique (ce qui est évidemment plus simple et plus sûr pour le ou la programmeur·se).

Ensuite, on grimpe d'un niveau (section 3 du RFC), avec les éléments, qui sont les données en entrée ou en sortie d'un processus cryptographique. Quand on dit « l'algorithme X prend en entrée un texte en clair et une clé secrète et produit un texte chiffré », le texte en clair, la clé et le texte chiffré sont des éléments. Dans le mécanisme hybride décrit dans draft-ietf-tls-hybrid-design, il y a deux clés publiques, qui sont deux éléments. Un élément peut à son tour être composé de plusieurs éléments.

On peut maintenant utiliser tout cela pour faire des protocoles (section 4). Un protocole hybride PQ/T est, comme vous vous en doutez, un protocole qui utilise au moins deux algorithmes, un classique et un après-quantique. C'est ce qui est proposé dans draft-ietf-tls-hybrid-design. Ce dernier est même composé (dans le mécanisme de désignation de la clé, le KEM). Alors que le mécanisme du RFC 9370 est hybride mais pas composé (on fait un échange de clés classique et un KEM après-quantique).

Les noms des services de sécurité qu'on souhaite utiliser vont de soi (section 5) : confidentialité hybride PQ/T (confidentialité assurée par un mécanisme hybride traditionnel/après-quantique) et authentification hybride PQ/T.

Idem pour les certificats (section 6). Un « certificat hybride PQ/T » contient au moins deux clés publiques, une pour un algorithme traditionnel et une pour un algorithme après-quantique (alors que le certificat traditionnel et le certificat après-quantique ne contiennent qu'un seul type de clés publique, comme c'est le cas du certificat décrit dans draft-ietf-lamps-dilithium-certificates).

Et merci à Magali Bardet pour sa relecture mais, bien sûr, les erreurs sont de moi et moi seul.

Téléchargez le RFC 9794


L'article seul

RFC 9803: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live (TTL) values

Date de publication du RFC : Juin 2025
Auteur(s) du RFC : G. Brown (ICANN)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 14 juin 2025

Traditionnellement, les registres de noms de domaine publiaient toutes les informations des sous-domaines avec la même durée de vie maximale (TTL : Time To Live). Certain·es client·es demandent à pouvoir choisir un TTL plus court (ou, parfois, plus long) et ce RFC décrit comment faire cela avec le protocole EPP.

Cet EPP, normalisé dans les RFC 5730 et suivants, est aujourd'hui le plus utilisé par les gros registres pour recevoir les commandes de leurs BE. (Cf. cet article de l'Afnic.) Tel que normalisé dans le RFC 5731, EPP ne permet pas, lors de la création d'un nom de domaine, de spécifier le TTL des enregistrements NS (NameServer) qui seront publiés. Prenons l'exemple de l'enregistrement d'un .fr. Le ou la titulaire va sur l'interface Web de son BE, réserve le nom cyberstructure.fr, le BE transmet la demande de création en utilisant EPP et le registre publie ensuite dans le DNS les informations de délégation, ici récupérées avec dig : 

% dig @d.nic.fr cyberstructure.fr NS    
…
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
…
;; AUTHORITY SECTION:
cyberstructure.fr.	3600 IN	NS puck.nether.net.
cyberstructure.fr.	3600 IN	NS fns2.42.pl.
cyberstructure.fr.	3600 IN	NS ns2.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns4.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns2.afraid.org.
cyberstructure.fr.	3600 IN	NS fns1.42.pl.
cyberstructure.fr.	3600 IN	NS ns1.bortzmeyer.org.
…

À aucun moment, la·e titulaire ou le BE n'a spécifié de TTL (les 3 600 secondes), il a été choisi par le registre seul. Certain·es titulaires peuvent pourtant avoir des préférences différentes. (Je rappelle que la notion de TTL est définie rigoureusement dans le RFC de terminologie DNS, le RFC 9499, voir sa section 5.)

Si vous voulez creuser ce concept de délégation, l'article de l'Afnic sur DELEG l'explique dans sa première partie.

L'exemple ci-dessus montrait les enregistrements NS (NameServer) mais ce problème concerne aussi les DS (RFC 9364), la colle et les éventuels DNAME (par exemple pour mettre en œuvre le RFC 6927).

Ce RFC normalise une extension à EPP pour permettre au client (le BE) d'indiquer le TTL souhaité pour la délégation. (Ce qui ne signifie pas que le registre satisfera ce souhait, lisez plus loin.) Plus précisément, il étend les classes (mappings) EPP pour les noms de domaine (RFC 5731 et pour les serveurs de noms (RFC 5732), les seules classes concernées par le DNS (rappelez-vous qu'EPP n'est pas limité aux noms de domaine, c'est un protocole d'avitaillement générique).

La section 1.2 du RFC contient les informations essentielles. D'abord, l'espace de noms urn:ietf:params:xml:ns:epp:ttl-1.0 (enregistré à l'IANA), qui identifie cette extension (le RFC utilise l'alias ttl mais rappelez-vous qu'en XML, c'est l'espace de noms qui compte, l'alias est choisi par l'auteur du document XML). Ensuite, l'élément <ttl:ttl> (donc, en complet, {urn:ietf:params:xml:ns:epp:ttl-1.0}ttl), qui peut être ajouté aux demandes EPP ou aux réponses. Parmi ses attributs :

  • for (le seul qui soit obligatoire) indique le type de données DNS auxquelles l'élément s'applique (uniquement des types concernés par la délégation, NS, DS, DNAME, A et AAAA, ainsi que la valeur spéciale custom, qu'il faut compléter un attribut custom qui suit l'expression rationnelle de la section 3.1 du RFC 6895, et évidemment utilise un type enregistré),
  • min (uniquement dans les réponses) qui indique la valeur minimale que le serveur (donc le registre) accepte (le registre est toujours libre de sa politique et peut refuser une valeur trop basse ou trop haute, répondant avec le code d'erreur EPP 2004, Parameter value range error),
  • max, la contrepartie de min, avec les mêmes propriétés,
  • default, qu'on ne trouve également que dans les réponses, et qui permet de connaitre la valeur qu'utiliserait le serveur si le client ne demande rien de spécifique.

L'élement <ttl:ttl> a pour contenu une valeur en secondes. Si cette valeur est vide, le serveur prendra la valeur par défaut (mais autant ne pas mettre d'élement <ttl:ttl> dans ce cas).

L'extension de ce RFC décrit des possibilités mais le registre, qui gère le serveur EPP, reste libre de ne pas tout accepter. Par exemple, il peut refuser l'utilisation de l'attribut custom, ou bien la restreindre à certains types (et, si le client demande quand même, répondre avec le code d'erreur EPP 2306 Parameter value policy error). Les types qui ont une syntaxe privilégiée (pas besoin de l'attribut XML custom) sont ceux qu'on peut actuellement trouver au dessus de la coupure de zone (section 7 du RFC 9499).

Vous avez noté que, dans les types qui ont une syntaxe privilégiée dans ce RFC, il y a les types pour les adresses IP. Ils sont utilisés pour la colle DNS (section 7 du RFC 9499), si le serveur EPP met en œuvre la classe EPP pour les serveurs de noms (RFC 5732).

Un deuxième élément XML est spécifié par ce RFC, <ttl:info>, qui sert à demander ou à indiquer des informations sur la politique du serveur (voir des exemples plus loin).

La section 2 décrit dans quelles commandes EPP on peut ajouter les nouveaux éléments. Je ne vais pas toutes les détailler, juste montrer quelques exemples du XML envoyé et des réponses. Ainsi, ici, le client va utiliser la commande <epp:info> pour se renseigner sur la politique du serveur : 


…
   C:     <info>
   C:       <domain:info
   C:        xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:       </domain:info>
   C:     </info>
   C:     <extension>
   C:       <ttl:info
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"
   C:         policy="false"/>
   C:     </extension>
   …

Et la réponse du serveur : 


…
   S:   <response>
   S:     <result code="1000">
   S:       <msg>Command completed successfully</msg>
   S:     </result>
   S:     <resData>
…
   S:         <domain:name>example.com</domain:name>
   S:         <domain:status s="ok"/>
…
   S:     </resData>
   S:     <extension>
   S:       <ttl:infData
   S:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   S:         <ttl:ttl for="NS">172800</ttl:ttl>
   S:         <ttl:ttl for="DS">300</ttl:ttl>
   S:       </ttl:infData>
…
   S:   </response>
…

Le serveur indique que le TTL des enregistrement NS sera de deux jours. Sinon, vous avez repéré le policy="false" ? S'il avait été à true, le serveur aurait renvoyé l'information sur sa politique pour tous les types d'enregistrements DNS (section 2.1.1.2).

Créons maintenant un nom de domaine en spécifiant un TTL : 


   C:   <command>
   C:     <create>
   C:       <domain:create
   C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:         <domain:name>example.com</domain:name>
   C:         <domain:ns>
   C:           <domain:hostObj>ns1.example.com</domain:hostObj>
   C:           <domain:hostObj>ns1.example.net</domain:hostObj>
   C:         </domain:ns>
   C:       </domain:create>
   C:     </create>
   C:     <extension>
   C:       <ttl:create
   C:         xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0">
   C:         <ttl:ttl for="NS">172800</ttl:ttl>
   C:         <ttl:ttl for="DS">300</ttl:ttl>
   C:       </ttl:create>
   C:     </extension>
   C:   </command>
   C: </epp>

Cela marcherait aussi dans un <domain:update>, pour changer les TTL.

Je l'ai déjà dit plusieurs fois, la demande du client ne va pas forcément être honorée par le serveur. La section 3 de notre RFC détaille l'interaction entre cette demande et la politique du serveur (donc du registre). Ainsi, le serveur peut limiter les types d'enregistrement DNS à qui ces commandes s'appliquent, par exemple en n'acceptant de changer le TTL que pour les DS (d'où l'intérêt des demandes avec policy=…, pour savoir à l'avance).

D'autre part, le TTL des enregistrements publiés peut changer en dehors d'EPP, par une action du registre. Auquel cas, le registre (section 4) peut gentiment prévenir ses clients par le système de messagerie du RFC 8590.

La possibilité pour le client d'indiquer un TTL souhaité a aussi des conséquences opérationnelle (section 5). Ainsi, des TTL courts vont accroitre la charge sur les serveurs faisant autorité puisque les résolveurs auront besoin de demander plus souvent, les expirations se rapprochant. Souvent, les utilisateurs veulent des TTL courts, pour la réactivité, et n'ont pas conscience des conséquences, d'autant plus que l'utilisation des serveurs DNS faisant autorité est gratuite pour eux. C'est pour cela que le registre peut fixer des valeurs minimales (et maximales, pour traiter d'autres problèmes) aux TTL souhaités par le client.

Une erreur parfois commise est de penser qu'un changement du TTL (via une commande EPP <epp:update>) va se voir instantanément. Mais, en fait, les informations, avec l'ancien TTL, sont encore dans la mémoire de plusieurs résolveurs. Il est donc recommandé de planifier les changements à l'avance, en tenant compte de cette mémorisation (section 5.2 du RFC). D'ailleurs, la politique du registre aussi peut changer, et les TTL par défaut, ainsi que les valeurs maximales et minimales, sont susceptibles d'être modifiées (un registre sérieux va informer ses utilisateurices de ces changements mais parfois, c'est oublié).

Un gros morceau de notre RFC est consacré à la sécurité (section 6) car les TTL ont une influence sur ce sujet. Premièrement, le fast flux (changement rapide des données de délégation DNS, cf. RFC 9499, section 7). Des malveillants utilisent cette technique pour rendre l'investigation numérique plus difficile et pour échapper à certaines règles de filtrage (voir le rapport SAC-025 du SAAC). Un TTL court peut faciliter ce changement rapide. Le rapport du SAAC suggère un TTL minimum de 30 minutes et/ou de limiter le nombre de changements qu'on peut faire par jour.

Si un malveillant réussit à obtenir les secrets qui lui permettent de soumettre des demandes de modification (au passage, pensez à activer l'authentification à plusieurs facteurs), il mettra sans doute des TTL très élevés pour que son détournement dure plus longtemps. D'où l'intérêt d'une valeur maximale pour les TTL.

Notre extension à EPP pour les TTL figure désormais dans le registre IANA des extensions et sa syntaxe complète, si vous êtes curieux·se, figure dans la section 8 (au format des schémas XML). Question mises en œuvre, vous en trouverez au moins deux, dans le SDK de Verisign et dans le logiciel Pepper (plus exactement dans la bibliothèque qu'il utilise, Net::EPP).

Téléchargez le RFC 9803


L'article seul

Même les systèmes de censure ont des bogues

Première rédaction de cet article le 11 juin 2025

Le dispositif de censure de l'Internet en Chine comprend de nombreux composants. L'un d'eux est une injection de fausses réponses DNS par des équipements réseau (et pas, comme c'est courant en Europe, par un résolveur menteur). Comme tout logiciel, il a des bogues, et même des bogues menant à des failles de sécurité. C'est le cas de Wallbleed, une intéressante bogue, étudiée dans un article détaillé. Cette bogue permet d'observer plusieurs choses sur le système de censure chinois, par exemple ses pratiques de correction des bogues.

Prenons l'article dans l'ordre et sautons l'avertissement éthique ajouté par les organisateurs de la conférence NDSS (nous y reviendrons plus tard). D'abord, un petit rappel sur le fonctionnement du GFW, le Great Firewall of China. En dépit de ce que pourrait faire croire ce terme journalistique, il n'y a pas un dispositif unifié mais un ensemble de dispositifs visant à empêcher le citoyen de base de s'informer ou de témoigner. C'est techniquement très efficace : si un des dispositifs est contournable, les autres pourront quand même censurer. Un de ces dispositifs est la génération de fausses réponses DNS. Rien à voir avec les résolveurs menteurs. Ici, la fausse réponse est générée par un équipement du réseau qui, observant une requête DNS pour un nom censuré, envoie une réponse mensongère, avant celle du vrai serveur. Pas besoin d'aller en Chine pour tester ce dispositif, il suffit d'écrire à une adresse IP située en Chine, même si elle n'a pas de serveur DNS actif (puisque la réponse est fabriquée par le réseau). Essayons un nom non censuré, puis un nom censuré : 


 % dig @113.113.113.113 coca-cola.com
;; communications error to 113.113.113.113#53: timed out
…
;; no servers could be reached

% dig @113.113.113.113 rsf.org      

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @113.113.113.113 rsf.org
…
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10926
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
rsf.org.		73 IN A	108.160.162.98

;; Query time: 209 msec
;; SERVER: 113.113.113.113#53(113.113.113.113) (UDP)
;; WHEN: Wed Jun 11 10:38:28 CEST 2025
;; MSG SIZE  rcvd: 52

On le voit, bien qu'aucun serveur DNS n'existe sur 113.113.113.113 (qui est chez China Telecom), la censure a fabriqué une fausse réponse pour rsf.org (l'adresse IP renvoyée, qui est chez Dropbox, n'a aucun rapport avec RSF et ne répond pas).

C'est dans le code de la machine qui génère cette fausse réponse que se situe la bogue Wallbleed. Pour la comprendre, un petit mot sur le format des paquets DNS (vous avez tous les détails dans le RFC 1034, section 3.1 et le RFC 1035, section 4.1). Les noms de domaine dans le paquet ne sont pas représentés avec des points mais sous la forme d'un octet indiquant la taille du composant qui suit. rsf.org va être représenté par {3, r, s, f, 3, o, r, g, 0}. La forme texte n'est que pour les humains. Conséquences pratiques : on peut mettre des points ou bien l'octet nul dans un nom de domaine, et c'est là-dessus que repose l'exploitation de la faille. (Il y a d'autres pièges dans l'analyse d'un paquet DNS, comme le fait que le nombre d'entrées dans chaque section peut être différent de la valeur indiquée dans l'en-tête DNS. Faites attention si vous écrivez du code. Les sections 3 et 4 du RFC 9267 détaillaient déjà des failles analogues à Wallbleed. Si un programme comme Drink a de nombreux tests d'analyse du paquet, ce n'est pas pour rien.)

Car les auteurs du dispositif de censure n'ont pas lu le RFC 9267. Comme le montre les expériences des auteurs de l'article, leur logiciel commence par traduire la forme binaire du nom de domaine en texte, puis la teste contre les noms censurés, apparemment stockés sous forme d'une expression rationnelle (l'article explique bien comment les chercheurs ont découvert cela). Si on envoie un nom écrit sous la forme {3, r, s, f, 4, o, r, g, 0, 120…}, il va être traduit sous forme d'une chaine de caractères rsf.org\000…, interprétée par le programme comme étant rsf.org (le caractère nul étant pris comme la fin de la chaine dans leur programme, apparemment écrit en C) et va donc déclencher la génération de la réponse mensongère. Le programme va alors copier le nom demandé dans la réponse mais, pour cela, il se fiera à la longueur du nom en binaire, plus de 120 caractères (l'octet indiquant une longueur 120, mis par le client, donc l'attaquant). Et il copiera donc dans la réponse bien plus d'octets qu'il n'y en avait dans rsf.org, prenant ces octets dans sa mémoire et faisant ainsi fuiter ce qu'elle contenait. Le nom de la faille fait évidemment référence à Heartbleed, qui permettait également de récupérer des informations contenues dans la mémoire du serveur bogué. Si vous êtes programmeuse ou programmeur en C, l'article contient d'ailleurs une mise en œuvre du système de réponse, avec sa bogue, écrite par rétro-ingénierie, et qui permet de bien voir le problème.

Une fois cette faille découverte, les auteurs ont pu étudier plein de choses intéressantes. Par exemple, le fait que toutes les requêtes DNS passant par la Chine n'étaient pas vulnérables, cela dépendait du chemin suivi. Il y a donc apparemment plusieurs mises en œuvre du dispositif de censure par réponses DNS mensongères et toutes n'avaient pas la faille. De même, les auteurs ont pu étudier la correction de la bogue, en continuant à envoyer des paquets truqués : les responsables de la censure ont détecté la faille, et l'ont corrigé (en deux fois, la première correction ayant été insuffisante). À noter que certains réseaux chinois ont gardé la version boguée pendant plus longtemps, montrant que l'administration du dispositif de censure n'est pas centralisée.

Autre étude, qu'il y avait-il dans la mémoire de la machine de censure ? Apparemment du trafic réseau sans lien avec le DNS, indiquant que la machine de censure observait tout.

Cette étude est passionnante mais soulève plusieurs questions éthiques, que l'article détaille :

  • Les chercheurs récupèrent les données qui étaient dans la mémoire, et pouvaient donc obtenir des données sensibles,
  • Les chercheurs exploitaient activement une faille de sécurité,
  • Les chercheurs n'ont pas immédiatement prévenu le gouvernement chinois.

On l'a dit, ces questions éthiques ont mené à l'ajout dans l'article d'un avertissement très long (et qu'on voit très rarement dans ce genre d'articles), mis par les organisateurs de la conférence où la faille était publiée. Personnellement, je trouve que les auteurs de l'article ont très bien traité les problèmes éthiques et que ces organisateurs exagéraient beaucoup :

  • Si quelqu'un envoyait en clair des données sensibles en Chine, il ne devait pas trop s'étonner que plein de gens les récupèrent,
  • Le système de censure étant lui-même une attaque, le fait de l'« attaquer » n'est pas si grave que ça,
  • L'étude est très intéressante et utile et il est donc parfaitement normal de ne pas avoir prévenu tout de suite ; cette information du gouvernement chinois était prévue pour la fin de l'étude, mais, finalement, la faille a été découverte, apparemment de manière indépendante. (Les nombreux paquets envoyés par les chercheurs ont peut-être donné l'alerte.)

L'article seul

Fiche de lecture : L'invention du fact-checking

Auteur(s) du livre : Pascal Froissart
Éditeur : PUF
978-2-13-084728-1
Publié en 2024
Première rédaction de cet article le 11 juin 2025

C'est un passionnant livre d'histoire de la communication et des médias que le résultat de la recherche menée par l'auteur sur la rubrique « La clinique des rumeurs », publiée par le Boston Herald pendant la Deuxième Guerre mondiale. Ce premier essai de fact-checking, comme on ne disait pas encore à l'époque, posait déjà toutes les questions liées à la vérification des informations, et à l'attitude à avoir face à la propagande de l'adversaire.

Le contexte est rude : les États-Unis sont en guerre. On fait des recherches actives sur les meilleurs moyens de propagande (cf. le livre « Le cercle démocratique »). Le pays est divisé (les relais de la propagande nazie comme Lindbergh s'exprimaient encore librement il y a peu), le racisme est fort et limite l'enthousiasme de certains à combattre. La guerre est un terrain fertile pour la paranoïa. On voit des espions partout et certains estiment que l'Axe pourrait sérieusement affaiblir ses ennemis en lançant des rumeurs. Un groupe de gens a l'idée de créer une rubrique dans un journal peu connu, le Boston Herald, et la baptise Rumor clinic, opération qui aura un certain succès et suscitera des imitateurs. Chaque article suit le plan {exposition d'une rumeur, démenti officiel}. Par exemple, une rumeur dit que des milliers de cadavres de marins étatsuniens ont été retrouvé sur une plage de Long Island, victimes des sous-marins allemands. Une autre que le sang donné par les citoyens noirs pour les hôpitaux militaires faisait que, une fois donné à des soldats blancs blessés, les receveurs auraient des enfants noirs. L'auteur du livre a épluché les numéros du journal et retrace l'histoire de cette « clinique des rumeurs » et des innombrables débats qui ont accompagné cette expérience, avant que la « clinique » ne soit fermée, avant même la fin de la guerre, victime de ses propres défauts et de rivalités bureaucratiques entre services étatiques, certains soutenant le projet et d'autres le combattant.

Pascal Froissart n'est pas tendre avec la clinique des rumeurs (comparez avec l'article bien plus favorable de Wikipédia). Rumeurs non sourcées (peut-être même inventées par les journalistes ?), indifférence face au risque que citer une rumeur pourrait lui donner de l'importance, vérification des faits limitée à citer des autorités, souvent militaires (pas la source la plus fiable pendant une guerre !), zéro enquête journalistique, appels à la vigilance citoyenne, malgré le risque que cela tourne à la chasse aux sorcières (surtout quand on sait ce qui s'est produit après la guerre…), vision binaire des faits (il n'y a que le mensonge et la vérité et rien entre les deux), absence de recherche sérieuse sur le phénomène social de la rumeur (bien qu'un des plus ardents promoteurs du projet soit un chercheur en psychologie). Ces défauts sont d'ailleurs toujours d'actualité dans certains discours anti « fake news », qui considèrent que seule la parole officielle est valable et que la vérité est forcément binaire.

On croise dans ce livre de nombreux personnages fascinants, dont le rôle réel était souvent masqué par le brouillard de la propagande. Ainsi, je ne connaissais pas la journaliste et militante antiraciste Frances Sweeney dont l'auteur estime qu'elle n'a pas eu de rôle réel dans la clinique des rumeurs.

Je divulgâche : on ne sait pas réellement si ces rumeurs étaient organisées par l'Axe. La clinique des rumeurs donnait souvent dans le complotisme, affirmant que tout propagateur de rumeur était un agent ennemi, et cela s'étendait aux ouvrières dénonçant les profits des industries de l'armement. Mais cela n'a jamais été prouvé. De façon amusante, l'OSS a recruté un ancien de la clinique des rumeurs pour aller propager des rumeurs chez l'ennemi (avec un succès mitigé).

Une lecture passionnante et très utile, dans un monde où les guerres et les menaces de guerre servent souvent, comme d'habitude, à faire taire les voix dissidentes, et où le mensonge est largement propagé, aussi bien par le ridicule complotiste de comptoir que par le président des États-Unis.


L'article seul

Short documentation of my BGP API

First publication of this article on 6 June 2025

I manage a small API to get information from the BGP routing protocol. This is its documentation.

The service allows you to find the current origin AS for a given IP address. The data comes from the RIS, which does not have apparently a ultra-simple API. You get more or less what can be seen by any router located on the DFZ. Here, the API is very frugal: you call https://bgp.bortzmeyer.org/IP-ADDRESS and you get a plain text reply. This is an example with curl: 

% curl -i https://bgp.bortzmeyer.org/2001:500:2f::f

HTTP/2 200 
content-type: text/plain
…

2001:500:2f::/48 3557

So, the IP address 2001:500:2f::f is part of the prefix 2001:500:2f::/48 and is originated by AS 3557 (ISC).

If the reply is empty, it typically means the service does not have information about this address.

You can also add a prefix length at the end, after a slash.

Of course, it also works with the old version of IP: 

% curl  https://bgp.bortzmeyer.org/185.71.138.138 
185.71.138.0/24 14907

(originated by AS 14907, Wikimedia).

You can access information about the current knowledge of the service with a special request: 

% curl  https://bgp.bortzmeyer.org/info
OK: 1038593 IPv4 prefixes, 231512 IPv6 prefixes, 84914 AS

The service exists for some time now, but did not have its own documentation before june 2025. Note it can also be accessed on the fediverse by sending an IP address to @bgp@mastodon.gougere.fr (here is an example).

Source code and a bit more documentation are available at https://framagit.org/bortzmeyer/whichasn.


L'article seul

Premiers essais avec le résolveur public DNS4EU

Première rédaction de cet article le 5 juin 2025

On n'y croyait plus mais le résolveur DNS public DNS4EU est désormais disponible. Il ne présente pas d'intérêt pratique (il y a déjà beaucoup de résolveurs, y compris publics, y compris européens) mais c'est toujours bien d'élargir le parc. La diversité est une bonne chose.

Leur page d'accueil donne les adresses IP à utiliser, après des années d'attente. Comme tous les résolveurs sérieux, il a, en plus des traditionnels UDP et TCP, les transports DoT et DoH (mais pas DoQ mais, bon, ce dernier est nettement moins fréquent aujourd'hui). Comme tous les résolveurs sérieux, il a une adresse IPv4 et une IPv6. En fait, il a même plusieurs adresses dans chaque famille, correspondant à des niveaux de filtrage différents. Aucune de ces adresses n'est spécialement mémorisable, contrairement à dns.sb.

Premier test simple, avec l'adresse mise en avant, Protective Resolution (tiens, le site Web ne semble exister qu'en anglais, ce qui est curieux pour un projet européen) : 


% kdig +tls @2a13:1001::86:54:11:1 frnog.org
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 39597
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1400 B; ext-rcode: NOERROR
;; PADDING: 410 B

;; QUESTION SECTION:
;; frnog.org.          		IN	A

;; ANSWER SECTION:
frnog.org.          	86400	IN	A	213.186.34.12

;; Received 468 B
;; Time 2025-06-04 20:14:45 CEST
;; From 2a13:1001::86:54:11:1@853(TLS) in 190.0 ms

OK, tout marche, on s'en doutait, mais c'est bien de vérifier.

Ce premier service ment pour les noms qui sont utilisés à des fins malveillantes. Je n'ai pas de tels noms sous la main tout de suite alors j'ai regardé dans ma boite aux lettres de spams mais les noms testés sont tous acceptés.

D'autres services sont proposés, par exemple Protective resolution with child protection & ad-blocking. Si je l'essaie sur un site porno : 


% kdig +tls @2a13:1001::86:54:11:11 pornhub.com
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 679
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0

;; QUESTION SECTION:
;; pornhub.com.        		IN	A

;; ANSWER SECTION:
pornhub.com.        	1	IN	A	51.15.69.11

;; Received 45 B
;; Time 2025-06-04 20:22:52 CEST
;; From 2a13:1001::86:54:11:11@853(TLS) in 17.9 ms

L'adresse renvoyée n'a rien à voir avec Pornhub et elle héberge un serveur HTTP qui redirige ensuite vers… localhost. Bon, ça protège du porno, mais j'avoue ne pas comprendre le comportement du serveur HTTP.

Bien que ce service soit censé protéger de la pub, il dit la vérité (malheureusement) pour des noms comme google-analytics.com. Pour googletagmanager.com, il renvoie un amusant 0.0.0.0. Aucune utilisation n'est faite des EDE du RFC 8914, hélas, contrairement à ce que fait Google Public DNS quand il ment. Je n'ai pas encore vu de signe de censure étatique (par exemple au profit des ayant-droits).

Regardons maintenant son hébergement. Il utilise des adresses IP allouées à Whalebone, leader du consortium, ou bien à l'opérateur KCOM (mais elles restent à l'ancien nom, Mistral, les bases des RIR ne sont pas toujours bien fraiches). Voyons combien il y a d'instances différentes, avec Blaeu : 

%  blaeu-resolve --requested 200 --nsid --nameserver 2a13:1001::86:54:11:1  www.bortzmeyer.org
Nameserver 2a13:1001::86:54:11:1
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eiu-mil-01;] : 40 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-fra-01;] : 35 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-ams-01;] : 55 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-prg-01;] : 5 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-par-01;] : 33 occurrences 
[TIMEOUT] : 9 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-mad-01;] : 7 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-sto-01;] : 7 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: ;] : 2 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-waw-01;] : 2 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-sof-01;] : 1 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: None;] : 1 occurrences 
Test #107704910 done at 2025-06-04T18:31:21Z

À part les quelques cas où un relais transparent interceptait les requêtes DNS et renvoyaient un NSID (RFC 5001) trompeur, on voit qu'il y a actuellement neuf instances. (On voit un peu plus d'instances en utilisant l'adresse IPv4 du résolveur.) L'affichage du temps de réponse est compatible avec des serveurs entièrement en Europe (ce qui est logique pour un service européen, le résolveur indien a fait un choix analogue) : 

%  blaeu-resolve --old-measurement 107705432 --nsid --displayrtt --nameserver 86.54.11.1  www.bortzmeyer.org
Nameserver 86.54.11.1
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-par-01;] : 113 occurrences Average RTT 136 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-fra-01;] : 22 occurrences Average RTT 152 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eiu-mil-01;] : 10 occurrences Average RTT 137 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-prg-01;] : 5 occurrences Average RTT 138 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-ams-01;] : 31 occurrences Average RTT 117 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: None;] : 4 occurrences Average RTT 14 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-mad-01;] : 2 occurrences Average RTT 123 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: 90m8;] : 1 occurrences Average RTT 156 ms
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: ;] : 3 occurrences Average RTT 1 ms
[TIMEOUT] : 5 occurrences 
[2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-bud-01;] : 3 occurrences Average RTT 251 ms
Test #107705867 done at 2025-06-04T18:41:34Z

(Une première mesure, la 107705432, avait servi à remplir la mémoire des résolveurs, afin que le temps de réponse dépende surtout du résolveur, pas des serveurs faisant autorité interrogés. Elle avait indiqué --area West, donc l'Amérique.) Le temps de réponse permet de voir que le résolveur n'est pas sur le continent américain. Pour un résolveur censé servir essentiellement au public européen, c'est logique.

Curieusement, alors que le cahier des charges de DNS4EU prévoyait explicitement la mise en œuvre de la censure des 27 États membres de l'UE, je n'ai pas trouvé de domaine censuré. Même Sci-Hub marche : 


% kdig +nsid +tls @2a13:1001::86:54:11:11 sci-hub.se                                          
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14949
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1400 B; ext-rcode: NOERROR
;; NSID: 646E733465752D7061722D3031 "dns4eu-par-01"
;; PADDING: 392 B

;; QUESTION SECTION:
;; sci-hub.se.         		IN	A

;; ANSWER SECTION:
sci-hub.se.         	60	IN	A	186.2.163.219

;; Received 468 B
;; Time 2025-06-04 20:44:22 CEST
;; From 2a13:1001::86:54:11:11@853(TLS) in 58.3 ms

Sinon, je l'ai dit, avoir juste un autre résolveur DNS public n'est pas super intéressant. Parmi ceux qui existent en Europe :

Et il existe d'autres résolveurs européens, sans compter ceux de Wikipédia.

Sinon, sur les prétentions de DNS4EU à la souveraineté, vous pouvez lire l'article « How much EU is in DNS4EU? ».


L'article seul

Les Journées du Logiciel Libre à Lyon (et avec du DNS et DELEG)

Première rédaction de cet article le 4 juin 2025

Les 24 et 25 mai 2025, à Lyon, c'étaient les Journées du Logiciel Libre. Comme toujours, deux jours passionnants avec plein de gens bien. J'y ai fait une conférence sur le projet de réforme de la délégation DNS, DELEG.

Ma conférence portait sur un projet IETF en cours, projet de réforme fondamentale du mécanisme de délégation dans le DNS. Vous pouvez trouver en ligne mon support, son source et la vidéo de la conférence. Notez que, sur ce sujet (le projet DELEG), j'avais déjà fait un article sur le blog de l'Afnic. D'autre part, si vous voulez suivre le projet DELEG, le meilleur point de départ est le Datatracker de l'IETF.

Parmi les autres activités du week-end (je n'ai pas tout fait, le programme était riche !), il y avait (très vaguement dans un ordre d'intérêt décroissant pour moi) :

Comme l'année précédente, les JDLL se sont tenues à l'ENS. Le parc intérieur est superbe, et entretenu par des animaux consciencieux et des jardiniers talentueux. jdll-2025-buvette.jpg

Et bien sûr mille mercis aux nombreux·ses bénévoles qui ont travaillé pour cette édition des JDLL, très réussie comme d'habitude. Et, sinon, une image qui n'a rien à voir avec les JDLL, à part qu'elle a été prise au Musée des Confluences, à courte distance du site des JDLL (c'est le mammouth de Choulans) : jdll-2025-mammouth.jpg


L'article seul

Les randos paysannes, un exemple

Première rédaction de cet article le 1 juin 2025

Je ne vais pas parler d'informatique, pour changer. Cet article est consacré aux « randos paysannes », organisées par la Fédération Nationale Accueil Paysan pour faire découvrir les offres d'Accueil Paysan.

J'ai déjà parlé ici des vacances chez Accueil Paysan. Outre les joies de la campagne, ces vacances permettent de nombreuses rencontres avec des personnes passionnantes. Mais tout le monde ne connait pas Accueil Paysan, organisation souvent éclipsée par le marketing d'entreprises commerciales bien plus visibles. C'est une des motivations des randos paysannes : faire découvrir des membres d'Accueil Paysan. Le principe : on… randonne et on rencontre (et on mange, aussi). Et on parle aux chèvres : rando-paysanne-chevres.jpg

Ainsi, en mai de cette année, j'étais pendant cinq jours dans l'Aveyron, entre Cransac et Conques, à la rando organisée par Jean-Marie Delcamp. Le groupe comportait sept personnes et nous avons pu découvrir les beaux paysages (à cette époque, c'est très vert), et échanger avec des gens remarquables, aussi bien néoruraux qu'héritiers de très vieilles lignées paysannes. Difficile de citer tous ceux et toutes celles qui nous ont accueillis (merci mille fois à toutes et tous) donc je ne vais mentionner que l'association Serpentine, au Perdigal (près de Firmi), qui mène depuis des années un projet associatif particulièrement audacieux, au milieu de la forêt (« développer et promouvoir des activités agricoles, artisanales, sociales, pédagogiques, culturelles générant des dynamiques humaines et du lien social en milieu rural »).

Puisque dans les valeurs d'Accueil Paysan, il y a les communs, c'était l'occasion d'ajouter deux points sur OpenStreetMap, dont les habitats troglodytiques. rando-paysanne-troglo.jpg.

Bref, inscrivez-vous aux randos paysannes et allez randonner. C'est en général tout à fait accessible physiquement (ceux qui me connaissent savent que je ne suis pas spécialement sportif) et les paysages, les repas et les rencontres valent largement la peine (l'Aveyron, ça monte, parfois).

Et c'était vert (l'auteur de cet article est à droite) : rando-paysanne-equipe.jpg Merci à Laurent Duhamel pour les photos.


L'article seul

En cas d'abus, brisez la glace

Première rédaction de cet article le 23 mai 2025

Cet article raconte une petite anecdote avec un gros hébergeur Internet suite à un abus d'un de ses clients. Et en tire la leçon que le support des gros hébergeurs Internet est souvent inutile.

Donc, point de départ, un innocent serveur HTTP, https://www.langtag.net/, que j'héberge. Il n'a pas de robots.txt, parce que, eh bien, il n'y a pas de raison d'en mettre, le contenu est public, et les pages sont presque toutes statiques, et en nombre fini, donc les robots ne peuvent pas faire grand mal, même s'ils déconnent. (Au passage, le format de robots.txt est normalisé dans le RFC 9309.)

Or, un matin, voici ce que je vois dans le journal du serveur : 

47.128.121.124 - - [10/May/2025:07:31:21 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:22 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:23 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:24 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:25 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:26 +0000] "GET /robots.txt HTTP/1.1" 301 320 "https://langtag.net/robots.txt" "-" langtag.net
47.128.121.124 - - [10/May/2025:07:31:27 +0000] "GET /robots.txt HTTP/1.1" 301 320 "

Qu'est-ce que cela dit ? Que la machine 47.128.121.124 demande le robots.txt (jusque là, c'est normal), se fait rediriger par le serveur (le code HTTP 301 signifie une redirection, ici de langtag.net vers www.langtag.net) mais ignore cette redirection et redemande une seconde après le même fichier et encore et encore (je n'ai mis que quelques lignes mais il y en a des milliers). OK, cela n'a pas tué le serveur mais quand même, il n'y a aucune raison légitime à refaire la même demande toutes les secondes. (Si le robot avait suivi la redirection, il aurait eu un 404.)

Comme j'étais de bonne humeur, au lieu de mettre l'adresse IP sur une liste noire, je me dis que je vais prévenir l'hébergeur. Un coup de whois montre que cette adresse IP est chez AWS à Singapour et que le logiciel qui déconne est donc chez un client d'AWS. La même requête whois m'avait donné un contact pour signaler les abus, trustandsafety@support.aws.com. Jusque là, j'étais plutôt content car, avec beaucoup d'acteurs de l'Internet, trouver une adresse de courrier de contact est une galère, dans le meilleur des cas, on a un formulaire Web qui refuse d'envoyer votre demande en disant que votre adresse de courrier est illégale. Donc, j'écris poliment et j'ai une réponse automatique, et un numéro de ticket (55808142305). Chic, mon message n'a pas été rejeté ou classé comme spam.

Mais c'est ensuite que les choses se gâtent. La première réponse spécifique me dit qu'il s'agit d'un robot légitime et « si vous voulez bloquer le robot, écrivez un robots.txt », ce qui n'a rien à voir avec le problème et montre que l'humain (ou l'IA ?) qui a répondu n'a pas lu mon message.

Je réponds, toujours poliment, expliquant que le support d'AWS n'a pas répondu au problème et le message suivant me dit « le problème est chez vous, il n'y a pas de robots.txt ».

À ce stade, j'ai arrêté la discussion, ayant autre chose à faire que de parler avec des stagiaires sous-payés ou des IA bas de gamme. Manifestement, l'entité chargée de répondre aux rapports d'abus chez AWS ne sait même pas lire ce format de journal, pourtant très courant.

Les leçons à en tirer ? Évidemment que la plupart du temps, signaler un abus ne sert à rien. On lit parfois, quand on se plaint sur les réseaux sociaux, qu'il serait plus efficace de signaler le problème à l'opérateur plutôt que de râler à la cantonade, conseil qui serait très pertinent si la grande majorité des acteurs de l'Internet ne se comportaient pas comme AWS. (À leur décharge, il faut rappeler que la grande majorité des signalements sont également écrits par des humains incompétents ou des IA et que c'est également une perte de temps que de les lire.)

PS : quelqu'un a dû quand même transmettre un message car le robot fou a finalement stoppé.


L'article seul

RFC 9774: Deprecation of AS_SET and AS_CONFED_SET in BGP

Date de publication du RFC : Mai 2025
Auteur(s) du RFC : W. Kumari (Google), K. Sriram, L. Hannachi (USA NIST), J. Haas (Juniper Networks)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF idr
Première rédaction de cet article le 22 mai 2025

Dans le protocole de routage BGP, les annonces de routes sont marquées avec l'AS d'origine et avec les AS qui ont relayé l'annonce. Dans ce chemin des AS, on pouvait indiquer un ensemble d'AS, l'AS_SET (ainsi que l'AS_CONFED_SET). C'était déconseillé depuis le RFC 6472 et ce nouveau RFC 9774 l'interdit désormais. Le but est de simplifier BGP et notamment ses mécanismes de sécurité. Il faut maintenant forcément indiquer une suite ordonnée d'AS, une AS_SEQUENCE.

Ces AS_SET (et les AS_CONFED_SET du RFC 5065 mais je vais passer rapidement sur les confédérations) sont spécifiés par le RFC 4271, sections 4.3 et 5.1.2. Attention à ne pas confondre avec les objets de type as-set des bases des RIR comme, par exemple, celui de l'Afnic.

Un des inconvénients de ces AS_SET est que, puisqu'un ensemble n'est pas ordonné, il n'est pas évident de déterminer l'AS d'origine, le premier AS, ce qui est pourtant nécessaire pour la sécurité (ROV ou Route Origin Validation, cf. RFC 6811).

Pourquoi mettait-on des AS_SET alors ? Parce que c'est utile lorsqu'on effectue de l'agrégation de routes. L'agrégation, spécifiée dans les sections 9.1.2.2 et 9.1.4 du RFC 4271 est le mécanisme par lequel un routeur rassemble plusieurs routes en une route plus générale. Si les routes originales venaient de plusieurs AS, on pouvait les rassembler en un AS_SET. Mais, évidemment, cela brouille l'information sur la vraie origine d'une route. C'est pour cela que les techniques de sécurisation de BGP, comme le BGPsec du RFC 8205 ne s'entendent pas bien avec les AS_SET.

La section 3 est la partie normative du RFC : désormais, une machine qui parle BGP ne doit plus utiliser d'AS_SET ou d'AS_CONFED_SET dans les chemins d'AS de ses messages de mise à jour de routes. Une machine qui reçoit ce genre de messages doit les traiter comme une erreur et retirer les routes (cf. RFC 7606). Les techniques de sécurisation comme ROV (RFC 6811) ou BGPsec (RFC 8205) considèrent toute annonce incluant des AS_SET comme invalide.

Sur l'agrégation, voyez par exemple cette réponse sur StackExchange. La procédure désormais suggérée pour en faire (section 5) est d'indiquer comme AS d'origine du préfixe agrégé l'AS qui a fait l'agrégation (en s'assurant bien qu'il y a un ROA - RFC 6482). Les annexes A et B donnent des exemples détaillés.

Il est frappant de constater que la majorité des documentations BGP des routeurs continue à mettre AS_SET et AS_SEQUENCE sur un pied d'égalité, alors que le RFC 6472 date de déjà 14 ans.

Le RFC note que les AS_SET sont peu utilisés, et parfois mal (un AS_SET ne comportant qu'un seul AS, ou bien ayant des numéros d'AS spéciaux…). Cherchons un peu. Je prends une RIB (Routing Information Base) complète sur RouteViews. Elle est au format MRT (Multi-Threaded Routing Toolkit, RFC 6396). Passons là à travers bgpdump, produisant un fichier texte. Comment trouver les AS_SET ? J'ai simplement lu le code source de bgpdump : 

 if (space)
	    {
	      if (segment->type == AS_SET
		  || segment->type == AS_CONFED_SET)
		as->str[pos++] = ',';
	      else
		as->str[pos++] = ' ';
		}

OK, il y a des virgules entre les AS (et une autre partie du code montre que les AS_SET sont placés entre accolades). On peut alors chercher le fichier texte et trouver, par exemple, cette annonce : 

TIME: 04/16/25 12:00:02
TYPE: TABLE_DUMP_V2/IPV4_UNICAST
PREFIX: 45.158.28.0/23
FROM: 12.0.1.63 AS7018
ORIGINATED: 04/15/25 06:11:28
ASPATH: 7018 3356 3223 {8262,34224} 201200
NEXT_HOP: 12.0.1.63
COMMUNITY: 7018:5000 7018:37232

L'annonce du préfixe 45.158.28.0/23, dont l'origine est l'AS 201200, est passée par l'AS 8262 ou bien le 34224, ou bien il y a eu agrégation de deux routes, chacune passée par un de ces deux AS (mais cela n'a pas été marqué). Sur un looking glass, on voit le passage par le 8262 uniquement : 

Mon Apr 21 10:30:34.855 CEST
BGP routing table entry for 45.158.28.0/23
Paths: (3 available, best #2, not advertised to any peer)
  Path #1: Received by speaker 0
  174 3356 3223 8262 201200, (received-only)
    149.6.34.5 from 149.6.34.5 (38.28.1.70)
      Origin IGP, metric 17060, localpref 100, valid, external
      Community: 174:21100 174:22009
      Origin-AS validity: not-found
      …

Soit ce looking glass a reçu une autre annonce, soit son code n'affiche que l'un des AS de l'AS_SET.

Autre exemple, où l'AS_SET est à l'origine : 

TIME: 04/16/25 12:00:04
TYPE: TABLE_DUMP_V2/IPV4_UNICAST
PREFIX: 67.204.16.0/22
FROM: 89.149.178.10 AS3257
ORIGINATED: 04/10/25 00:44:05
ASPATH: 3257 13876 {15255,396519,396895}
NEXT_HOP: 89.149.178.10
MULTI_EXIT_DISC: 10
AGGREGATOR: AS13876 67.204.31.4
COMMUNITY: 3257:4000 3257:8118 3257:50002 3257:50120 3257:51100 3257:51110

Là, il y a eu agrégation, par l'AS 13876, qui a placé un AS_SET. Vu par le looking glass : 

   
Mon Apr 21 10:39:46.348 CEST
BGP routing table entry for 67.204.16.0/22
Paths: (3 available, best #2, not advertised to any peer)
  Path #1: Received by speaker 0
  174 3356 13876 {15255,396519,396895}, (aggregated by 13876 67.204.31.4), (received-only)
    149.6.34.5 from 149.6.34.5 (38.28.1.70)
      Origin IGP, metric 17060, localpref 100, valid, external
      Community: 174:21100 174:22009
      Origin-AS validity: not-found

Je ne suis pas sûr que tous les looking glass affichent correctement les AS_SET. Mais étant donné que notre nouveau RFC met les AS_SET à la poubelle, il ne servirait à rien de demander au développeur d'ajouter ce service. Ah, et mon bot fédivers qui lit la table BGP gère ça bien.

Téléchargez le RFC 9774


L'article seul

RFC 9676: A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)

Date de publication du RFC : Mai 2025
Auteur(s) du RFC : P. Spinosa, E. Francesconi (National Research Council of Italy (CNR)), C. Lupo
Pour information
Première rédaction de cet article le 21 mai 2025

Les textes de loi (et assimilés : décrets, par exemple) ne sont pas évidents à trouver et donc à citer. Ce RFC crée un espace URN (RFC 8141), lex, pour pouvoir identifier les textes juridiques. S'il est largement adopté par les juristes (ce n'est pas gagné…), il facilitera les références aux textes légaux. Ainsi,urn:lex:fr:etat:loi:2011-03-22;2011-302 pourrait identifier la loi n° 2011-302 portant diverses dispositions d'adaptation de la législation au droit de l'Union européenne en matière de santé, de travail et de communications électroniques, par exemple (elle change entre autres le régime applicable aux noms de domaine).

Comme toujours avec les URN (RFC 8141) et avec les URI en général, le but est d'attribuer des identificateurs uniques désignant une source de loi. Cette source peut être une loi, un décret, un texte d'une autorité de régulation, un jugement, etc. En revanche, les opinions et commentaires des juristes ne sont pas prévus. Comme avec tous les URN, l'identificateur ne dépend pas de la localisation en ligne d'un document (c'est un URN, pas un URL), ou même d'ailleurs de si le document est en ligne ou pas. Le but est que l'identificateur soit unique, et stable sur le long terme.

Le projet est né en Italie, sur la base du projet NormeInRete, datant de 2001. Des projets similaires existent dans d'autres pays. (Voir le livre « Technologies for European Integration; Standards-based Interoperability of Legal Information Systems ». Au niveau européen, voir « Law via the Internet; Free Access, Quality of Information, Effectiveness of Rights ».) Au niveau mondial, on peut noter que le document « Access to Foreign Law in Civil and Commercial Matters » pronait « State Parties are encouraged to adopt neutral methods of citation of their legal materials, including methods that are medium-neutral, provider-neutral and internationally consistent. ». Un tel système d'identificateurs est évidemment d'autant plus indispensable que l'inflation législative fait qu'on dépend tout le temps de textes de lois, et qu'on a besoin de les référencer dans de nombreux contextes. Toute ambiguïté dans cette référence serait bien sûr très gênante.

En pratique, le problème n'est pas trivial. Le mécanisme pour créer ces identificateurs doit être assez rigide pour assurer l'interopérabilité mais en même temps assez souple pour s'adapter aux évolutions futures. Et il doit être décentralisé car il n'y a pas d'institution mondiale supervisant les lois de tous les pays et chaque pays (voire davantage, notamment dans les États fédéraux) a déjà un mécanisme d'identification des lois.

L'approche choisie est donc un système hiérarchique, indiquant successivement le pays (via son TLD, ou via un nom de second niveau comme un.org pour l'ONU qui, curieusement, n'utilise pas son .int), la juridiction émettrice et enfin le document. On ne change donc pas les systèmes existants et on n'oblige pas les juridictions locales à adopter un système radicalement différent. La référence locale du document suit donc un schéma qui dépend de la juridiction, schéma qu'il n'est pas prévu d'uniformiser. Ainsi, urn:lex:eu:commission:directive:2010-03-09;2010-19-EU sera un texte européen (le eu), émis par la Commission, plus précisément ce sera une directive, la 2010-19-EU (la directive « modifiant la directive 91/226/CEE du Conseil et la directive 2007/46/CE du Parlement européen et du Conseil afin de les adapter aux progrès techniques dans le domaine des systèmes antiprojections de certaines catégories de véhicules à moteur et de leurs remorques »). Et urn:lex:be:conseil.etat:decision:2024-08-29;260.536 sera une décision du Conseil d'État belge (demande l’annulation de « la décision de non-classement et de non-retenue de la candidature notifiée par la partie adverse le 14 mars 2022 à la partie requérante »). Pour un pays fédéral, on aura une indication de l'entité qui émet le texte, par exemple urn:lex:br;sao.paulo:governo:decreto précédera l'identificateur d'un décret de l'État de São Paulo. (Notez le point-virgule, certains caractères sont réservés pour séparer des sous-champs dans l'URN, cf. section 3.2.)

Il devrait y avoir dans le futur un registre (pas un registre IANA) des codes identifiants les juridictions (section 2.2) du RFC mais, en septembre 2024, il n'était pas encore créé. Sa politique d'enregistrement sera « Examen par un expert » (« Expert review » du RFC 8126). Même en cas de changement géopolitique (fusion de deux pays, par exemple), les codes ne sont jamais réattribués, puisque les URN doivent être stables sur le long terme.

Les URN n'ont pas de mécanisme de résolution standard. Si on veut, à partir d'un URN, accéder à une ressource en ligne, il faut une méthode spécifique à chaque espace sous les URN. Pour lex, il est envisagé d'utiliser le DNS, en transformant l'URN en un URL, contenant un nom de domaine (section 10 du RFC, commentée plus loin). C'est d'ailleurs pour faciliter la correspondance avec les noms de domaine que le RFC (à tort, à mon avis), déconseille (section 3.4) d'utiliser des caractères non-ASCII dans les URN lex et donc d'utiliser un système de correspondance, depuis la langue de la juridiction concernée (urn:lex:de:stadt.muenchen:rundschreiben:... au lieu de urn:lex:de:stadt.münchen:rundschreiben:...). Si c'est assez évident pour l'italien ou le français (ministère → ministere), cela va nécessiter des correspondances plus élaborées dans d'autres cas. Si c'est vraiment trop difficile, le RFC recommande d'utiliser Unicode et, si on utilise le DNS et qu'on fait une correspondance en nom de domaine, de se servir de Punycode.

Quant au nom des juridictions, le RFC recommande de ne pas utiliser d'abréviations (même si elles sont courantes dans les textes juridiques), car elles ne sont pas toujours cohérentes. Donc, ministere et pas min.. Toujours pour des raisons d'uniformité, les dates doivent être en ISO 8601. [Encore une mauvaise idée : contrairement à ce qu'on lit souvent, cette norme ne garantit pas un format unique, loin de là. Utiliser le RFC 3339 aurait été une meilleure idée. Mais, en fait, le RFC suggère un profil réduit de ISO 8601 donc, en pratique, cela devrait marcher.]

Parmi les pièges amusants, il y a le fait que certains textes sont issus de plusieurs juridictions. C'est le cas des traités internationaux, par exemple. Si l'Espagne et le Portugal signent un accord, doit-il être sous urn:lex:es ou bien urn:lex:pt ? La solution du RFC (section 5.5) est simple : le texte a plusieurs URN (deux dans l'exemple ibérique ci-dessus). D'autres cas peuvent d'ailleurs se produire où un texte légal a plusieurs URN donc il n'y a pas d'URL « canonique » pour un texte. La fonction URN → texte est sans ambiguïté mais il n'y a pas de fonction texte → URN.

Maintenant, un peu de bureaucratie (section 9). Si je veux enregistrer un ou plusieurs URN lex, quelle est la marche à suivre ? D'abord, trouver le code de juridiction (en général le TLD du pays) puis l'organisation (registrar dans le RFC) chargée de gérer ce code. (Rappelez-vous que cette infrastructure n'existe pas encore.) Ces organisations doivent être stables sur le long terme, si on veut assurer la stabilité des identificateurs. Ensuite, comme chacune de ces organisations a sa propre politique, il faut suivre la politique en question.

Bon, c'est bien joli d'avoir des identificateurs stables. Mais, de nos jours, la plupart des utilisateurices voudraient davantage. Ils voudraient de l'opérationnel : je mets (je tape, je copie/colle…) un identificateur dans un navigateur et pouf, j'ai une jolie page avec le texte de loi ainsi identifié. Pour que ce beau projet fonctionne, il faut un système de résolution (section 10), qui va prendre en entrée un URN dans l'espace lex et nous donner un identificateur de plus bas niveau, un URL, par exemple, utilisable par le logiciel pour récupérer un contenu. La conception d'un tel système n'est pas triviale, entre autres parce que certains des URN lex seront invalides, par exemple lorsqu'ils auront été fabriqués automatiquement ou semi-automatiquement à partir de références informelles.

La méthode proposée dans cette section 10 (mais rappelez-vous que, pour l'instant, tout cela n'existe que sur le papier) est de s'appuyer sur le DNS et plus précisément sur les enregistrements de type NAPTR (normalisés dans le RFC 3404). Cela passera par le nom (déjà créé, cf. section 12 du RFC) lex.urn.arpa : 


% dig lex.urn.arpa NAPTR
…
;; ANSWER SECTION:
lex.urn.arpa.		86400 IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it.

Du point de vue gouvernance, il est prévu que le CNR maintienne la racine du système, notamment le serveur lex-nameserver.nic.it mentionné plus haut (ne cherchez pas à l'interroger, il semble ne pas avoir de données encore). Quand tout cela fonctionnera, un URN lex sera traduit en un URL (RFC 3405), par exemple quand le Brésil aura mis en place son système, et envoyé au CNR les informations nécessaires, urn:lex:br:senado:… sera traduit via les NAPTR en https://lex.senado.gov.br/… qui sera ensuite utilisé, par exemple par un navigateur.

L'espace lex a été enregistré (section 12) dans le registre des espaces de noms pour les URN via cette demande.

Téléchargez le RFC 9676


L'article seul

RFC 9771: Properties of AEAD Algorithms

Date de publication du RFC : Mai 2025
Auteur(s) du RFC : A. Bozhko (CryptoPro)
Pour information
Réalisé dans le cadre du groupe de recherche IRTF cfrg
Première rédaction de cet article le 8 mai 2025

Aujourd'hui, sur l'Internet, on n'utilise plus (ou, en tout cas, cela devrait être le cas) que des algorithmes de chiffrement AEAD (Authenticated Encryption with Associated Data). Ils assurent confidentialité et intégrité des données. Mais on peut être gourmand et vouloir en plus d'autres propriétés. Ce nouveau RFC classe ces propriétés et définit la terminologie.

Les algorithmes de chiffrement anciens, non-AEAD, assuraient la confidentialité, mais pas l'intégrité. Un méchant (ou un accident) pouvait modifier les données sans que ce soit détectable et le déchiffrement produisait ensuite un texte qui n'était pas le texte original. Bien sûr, s'il s'agissait d'un texte en langue naturelle, ou bien d'un texte dans un format structuré, l'utilisateurice pouvait parfois voir qu'il y avait eu un problème, puisque, avec certains modes de chiffrement, ielle ne récupérait que du n'importe quoi. Mais il serait souhaitable de détecter l'attaque (ou le problème) le plus tôt possible. Et il y a aussi des raisons de sécurité pour assurer confidentialité et intégrité en même temps. Sinon, certaines attaques (comme Poodle) sont possibles. Et il faut aussi compter avec le fait que les programmeurs peuvent se tromper s'ils doivent appliquer confidentialité et intégrité séparément (cf. RFC 7366).

Vérifier l'intégrité peut se faire avec une somme de contrôle avec clé (MAC), ou une technique équivalente mais l'AEAD fait mieux, en intégrant chiffrement et vérification de l'intégrité. Cela a plusieurs avantages, dont les performances (plus besoin de chiffrer et de calculer un MAC successivement) et, comme indiqué plus haut, la sécurité.

Dans la famille des normes de l'Internet, l'AEAD est décrit plus en détail dans le RFC 5116. À partir de la version 1.3 (normalisée dans le RFC 8446), TLS impose l'utilisation d'algorithmes AEAD. Même chose pour QUIC (RFC 9000). Parmi les algorithmes AEAD courants, on trouve AES-GCM et ChaCha20-Poly1305 (RFC 8439) mais aussi Aegis ou OCB (RFC 7253).

Au passage, je trouve que le terme en anglais, authenticated encryption et sa traduction en français, chiffrement authentifié, sont trompeurs. Le service qu'ils assurent n'est pas l'authentification telle qu'on peut la faire avec RSA ou ECDSA. Je préférerais qu'on parle de chiffrement intègre.

Tout cela est bien connu depuis des années. Mais l'appétit vient en mangeant et certaines utilisations bénéficieraient de services supplémentaires. Les algorithmes existants sont sûrs par rapport aux modèles de menace « traditionnels » mais il en existe d'autres, auxquels tous les algorithmes AEAD ne répondent pas forcément. Ces services supplémentaires, pour répondre à ces modèles de menace, existaient parfois, et parfois ont déjà été développés, mais des équipes différentes leur donnent des noms différents. D'où le projet d'unification de la terminologie de ce RFC 9771. Il présente les propriétés supplémentaires (en plus de la confidentialité et de l'intégrité, que tout algorithme AEAD fournit), des noms d'algorithmes qui les fournissent et des cas d'usage. Le but est que les futurs RFC normalisant des protocoles qui dépendent de ces propriétés utilisent le vocabulaire de notre RFC.

Les propriétés supplémentaires, au-delà de la confidentialité et de l'intégrité basiques, sont listées dans la section 4. Il y a deux catégories :

  • Propriétés de sécurité, lorsque la propriété permet de parer certaines attaques,
  • propriétés de mise en œuvre, lorsqu'elles permettent de meilleures implémentations,
  • et, pour, voir si vous savez compter jusqu'à deux, il y a aussi une catégorie un peu fourre-tout, pour les propriétés qui ajoutent de nouvelles fonctions, mais je n'en parlerai pas plus ici (consultez l'annexe A du RFC).

Avant d'exposer les propriétés additionnelles, le RFC présente les traditionnelles, en suivant le même schéma (définition, exemples, éventuels synonymes, cas d'usage, lectures pour approfondir) : confidentialité et intégrité sont ainsi exposées. Passons ensuite aux choses sérieuses, avec les propriétés de sécurité supplémentaires.

D'abord, la sécurité face aux changements (blockwise security) : c'est le fait d'être sûr même quand un adversaire particulièrement puissant peut modifier le texte en clair en fonction de ce qui a déjà été chiffré. Tous les adversaires n'ont heureusement pas ce pouvoir mais cela peut arriver, par exemple lors du streaming. Ainsi, la famille Deoxys résiste à ce type d'attaque.

Ensuite, l'engagement complet (full commitment). C'est l'extrême difficulté à trouver deux jeux {clé, numnique, données en clair} qui donneront le même texte chiffré. Cela sert dans le message franking mais ne me demandez pas ce que c'est, lisez cet article. Ascon a cette propriété. Et, au passage, le AD de AEAD veut dire « données associées » (associated data, des méta-données ajoutées au message) et les « données en clair » incluent donc ces données associées.

La résistance aux fuites (leakage resistance) est une propriété des algorithmes cryptographiques (pas seulement AEAD) dont la sécurité ne diminue pas même si l'attaquant obtient des informations via un canal secondaire. Un exemple d'un tel canal secondaire est le temps de calcul (si l'attaquant peut le chronométrer et si l'algorithme n'est pas résistant aux fuites, l'attaquant pourra obtenir des informations sur la clé) ou bien la consommation électrique. Bien sûr, cela dépend de l'implémentation (essayer de faire tous les calculs en un temps constant, quelle que soit la clé) mais un algorithme résistant aux fuites est un algorithme qui ne dépend pas trop (mild requirement, dit le RFC) de son implémentation concrète pour être sûr. Cette propriété est particulièrement importante pour les machines que l'attaquant peut contrôler physiquement (cartes à puce, objets connectés) alors que mesurer le temps de calcul, et a fortiori la consommation électrique, d'un serveur Internet distant est une autre affaire. (Mais ça reste possible dans certains cas, notamment si l'attaquant est proche, par exemple chez le même hébergeur : voir l'article « Remote Timing Attacks Are Practical » ou bien la faille Hertzbleed.)

La sécurité multi-utilisateurs (multi-user security) est atteinte quand la sécurité décroit moins vite que linéairement avec le nombre d'utilisateurs (les algorithmes ont des limites quantitatives, cf. draft-irtf-cfrg-aead-limits). C'est indispensable pour des protocoles comme TLS, où plusieurs « utilisateurs » peuvent se retrouver sur la même session TLS. Des algorithmes comme AES-GCM ou ChaCha20-Poly1305 ont cette sécurité (si on ne dépasse pas les limites). Vous pouvez lire « The Multi-user Security of Authenticated Encryption: AES-GCM in TLS 1.3 » pour les détails.

Bien sûr, il fallait mentionner la propriété de résistance aux calculateurs quantiques (Quantum security). AEAD ou pas, un algorithme est résistant au quantique si on ne connait pas d'algorithme pour calculateur quantique capable de casser cet algorithme. Les algorithmes comme AES-GCM ou ChaCha20-Poly1305 sont ainsi résistants (au prix parfois d'une augmentation raisonnable de la taille de la clé). Cette résistance permet de faire face au cas où un indiscret stocke aujourd'hui des messages qu'il ne sait pas déchiffrer, en attendant qu'il dispose d'un calculateur quantique. Notez que si on fait face à un adversaire mieux armé, qui n'a pas seulement un calculateur quantique mais peut en plus accéder à l'état quantique de votre système de chiffrement, ça devient plus compliqué. Dans ce cas très futuriste, il faut passer à des algorithmes comme QCB (cf. « QCB: Efficient Quantum-Secure Authenticated Encryption »).

Tout cela, c'étaient les propriétés de sécurité des algorithmes, liés à la définition de ces algorithmes. Mais, en pratique, on n'utilise pas un algorithme mais une mise en œuvre de l'algorithme, réalisée dans un programme. La section 4.4 du RFC liste des propriétés souhaitables des mises en œuvre (en plus de la propriété évidente que le programme soit rapide), propriétés qui n'affectent pas la sécurité (que ce soit en bien ou en mal). Par exemple, on souhaite que le programme soit léger, au sens où il tourne sur des machines contraintes (en mémoire, en processeur, en énergie, etc). Le rapport du NIST « NISTIR 8114 - Report on Lightweight Cryptography » est une lecture intéressante à ce sujet.

On souhaite ensuite un programme qui puisse exploiter le parallélisme de la machine qui l'exécute. Si celle-ci a plusieurs processeurs et/ou plusieurs cœurs, il serait bon que le travail puisse être réparti entre ces cœurs. Des algorithmes comme le mode CBC ne permettent pas le parallélisme lors du chiffrement.

Autres propriétés souhaitables citées par le RFC : ne pas nécessiter un travail supplémentaire ou de nouvelles ressources quand on introduit une nouvelle clé, fonctionner en une passe unique sur les données, permettre de chiffrer un flux de données continu, sans attendre sa fin…

Merci beaucoup à Manuel Pégourié-Gonnard et Florian Maury pour une relecture détaillée avec plein de bonnes remarques. Comme toujours, les erreurs et approximations sont de moi, pas des relecteurs.

Téléchargez le RFC 9771


L'article seul

RFC 9292: Binary Representation of HTTP Messages

Date de publication du RFC : Août 2022
Auteur(s) du RFC : M. Thomson (Mozilla), C. A. Wood (Cloudflare)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF httpbis
Première rédaction de cet article le 5 mai 2025

Un message HTTP est traditionnellement représenté comme du texte mais ce RFC spécifie une alternative, une représentation binaire d'un message.

À quoi ça sert ? L'un des buts est de faciliter la transmission de messages HTTP (requêtes ou réponses, cf. RFC 9110) par d'autres protocoles que HTTP. C'est ainsi que l'oblivious HTTP du RFC 9458 utilise ce format binaire. D'autre part, un format binaire a des chances d'être plus compact. (Le RFC dit aussi que cela permet l'application du chiffrement intègre, mais ce serait le cas aussi avec du texte, je trouve.) Et l'analyse d'un tel format est plus simple, avec moins de pièges que celle du format texte, qui mènent parfois à des failles de sécurité (voir par exemple la section 11 du RFC 9112). Comme vous le savez, les versions 2 et 3 de HTTP encodent déjà l'en-tête en binaire et leurs spécifications (RFC 9113 et RFC 9114) ont servi de base à ce nouveau RFC. Le nouveau format a le type message/bhttp (le format traditionnel étant message/http).

On peut encoder le message HTTP en binaire suivant deux modes. Le premier préfixe tous les éléments par leur longueur, ce qui est plus efficace. Le deuxième ne le fait pas, ce qui permet de commencer à encoder sans connaitre la longueur finale.

Notez bien que c'est la sémantique du message qui est encodée, pas sa représentation texte. Concrètement, cela veut dire qu'un message HTTP représenté en texte, traduit en binaire, puis re-traduit en texte ne sera pas identique au bit près.

Bon, mais c'est quoi un message HTTP ? La section 6 du RFC 9110 nous l'apprend. S'il peut être encodé de plusieurs manières, la vision abstraite du message est toujours la même : le message est une requête ou une réponse, s'il est une requête, il y a une méthode (GET, PUT, etc) et la ressource demandée, s'il est une réponse, un code de retour (comme le fameux 404), puis dans les deux cas, un en-tête (avec les champs comme Host: ou Content-Type:), un corps (qui, comme l'en-tête, peut être vide), un pied (en général absent), et parfois du remplissage. Dans notre encodage en binaire, le fait que le message soit une requête ou une réponse sera indiqué par le framing indicator, qui vaut 0 dans le premier cas et 1 dans le second, pour le mode à longueur connue, et 2 ou 3 pour le mode à longueur pas connue à l'avance (section 3.3).

Le reste de ce que vous devez savoir sur ce format est dans les sections 3.4 (pour les requêtes) et 3.5 (pour les messages). Mais on va voir cela avec des exemples (la section 5 du RFC en contient plusieurs) et du code qui tourne.

Puisque ce format binaire est, à l'heure actuelle, surtout utilisé par oblivious HTTP, on va se tourner vers les mises en œuvre de cette technique. Prenons ohttp. Il est écrit en Rust. Les instructions de compilation marchent bien, je les résume ici (c'était pour une machine Arch) : 


export workspace=$HOME/tmp
sudo apk add mercurial gyp ca-certificates coreutils curl git make mercurial clang llvm lld ninja-build 
cd $workspace
git clone https://github.com/martinthomson/ohttp.git
git clone https://github.com/nss-dev/nss ./nss
hg clone https://hg.mozilla.org/projects/nspr ./nspr
export NSS_DIR=$workspace/nss
export LD_LIBRARY_PATH=$workspace/dist/Debug/lib
cd ohttp
cargo build
cargo test

Et commençons par encoder une simple requête (je vous rappelle que la section 5 du RFC, et le répertoire examples/ de ohttp contiennent d'autres exemples, y compris plus complexes) : 


% cat request-1.txt 
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.framasoft.fr
   
% ./ohttp/target/debug/bhttp-convert < ./request-1.txt > request-1.bin

(Attention, le fichier texte doit avoir des fins de ligne CR-LF, comme le prescrit la norme HTTP et il doit y avoir une ligne vide à la fin. Si vous éditez avec emacs sur une machine Unix, C-x RET f puis dos). Regardons le fichier binaire produit (on aurait aussi pu utiliser od, ou bien emacs avec l'excellent mode hexl-mode) : 

% xxd request-1.bin 
00000000: 0003 4745 5405 6874 7470 7300 0a2f 6865  ..GET.https../he
00000010: 6c6c 6f2e 7478 7440 560a 7573 6572 2d61  llo.txt@V.user-a
00000020: 6765 6e74 3463 7572 6c2f 372e 3136 2e33  gent4curl/7.16.3
00000030: 206c 6962 6375 726c 2f37 2e31 362e 3320   libcurl/7.16.3 
00000040: 4f70 656e 5353 4c2f 302e 392e 376c 207a  OpenSSL/0.9.7l z
00000050: 6c69 622f 312e 322e 3304 686f 7374 1077  lib/1.2.3.host.w
00000060: 7777 2e66 7261 6d61 736f 6674 2e66 7200  ww.framasoft.fr.
00000070: 00                                       .

Le premier octet est le framing indicator, encodé selon la section 16 du RFC 9000 (dans le source de ohttp, regardez bhttp/src/rw.rs). Il vaut zéro, indiquant une requête de longueur connue. Le deuxième octet, de valeur trois, indique la longueur de la méthode HTTP, puis suivent les octets de cette méthode (G E T).

Encodons ensuite une réponse : 


% cat response-1.txt 
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Content-Length: 51
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.

% ./ohttp/target/debug/bhttp-convert < ./response-1.txt > response-1.bin

% xxd response-1.bin
00000000: 0140 c840 a104 6461 7465 1d4d 6f6e 2c20  .@.@..date.Mon, 
00000010: 3237 204a 756c 2032 3030 3920 3132 3a32  27 Jul 2009 12:2
00000020: 383a 3533 2047 4d54 0673 6572 7665 7206  8:53 GMT.server.
00000030: 4170 6163 6865 0d6c 6173 742d 6d6f 6469  Apache.last-modi
00000040: 6669 6564 1d57 6564 2c20 3232 204a 756c  fied.Wed, 22 Jul
00000050: 2032 3030 3920 3139 3a31 353a 3536 2047   2009 19:15:56 G
00000060: 4d54 0465 7461 6714 2233 3461 6133 3837  MT.etag."34aa387
00000070: 2d64 2d31 3536 3865 6230 3022 0e63 6f6e  -d-1568eb00".con
00000080: 7465 6e74 2d6c 656e 6774 6802 3531 0c63  tent-length.51.c
00000090: 6f6e 7465 6e74 2d74 7970 650a 7465 7874  ontent-type.text
000000a0: 2f70 6c61 696e 3348 656c 6c6f 2057 6f72  /plain3Hello Wor
000000b0: 6c64 2120 4d79 2063 6f6e 7465 6e74 2069  ld! My content i
000000c0: 6e63 6c75 6465 7320 6120 7472 6169 6c69  ncludes a traili
000000d0: 6e67 2043 524c 462e 0d0a 00              ng CRLF....

Ici, le framing indicator vaut un, indiquant une réponse de longueur connue. Vous avez vu le C8 en troisième position ? C'est le code de retour 200.

Le format binaire de HTTP a été enregistré sous le nom message/bhttp.

Ah, et il existe au moins une autre mise en œuvre de ce RFC, en Go, dans ohttp-go.

Téléchargez le RFC 9292


L'article seul

Fiche de lecture : Between Two Rivers

Auteur(s) du livre : Moudhy Al-Rashid
Éditeur : Hodder Press
978-1-529-39213-5
Publié en 2025
Première rédaction de cet article le 28 avril 2025

Le titre fait référence à la Mésopotamie, étymologiquement « entre deux fleuves ». Ce livre (en anglais) présente divers aspects de la vie dans la Mésopotamie antique, à travers plusieurs personnes dont les noms et les activités ont franchi les siècles, grâce à une invention géniale : l'écriture.

L'auteure est historienne, spécialiste de la Mésopotamie et tient un compte Twitter très vivant, avec plein de descriptions d'inscriptions anciennes. Ici, le point de départ est le palais de la princesse Ennigaldi-Nanna, où se trouve toute une collection d'objets qui, même pour l'époque, étaient antiques. Un musée ? Une bibliothèque ? Un hobby ? En tout cas, Ennigaldi-Nanna n'est que l'une des personnes qui sont citées dans le livre. Car les gens de la Mésopotamie, ayant inventé l'écriture, ont beaucoup utilisé leur invention. Poèmes, romans, ouvrages historiques, liste de marchandises, documents comptables, correspondance diplomatique, ils et elles ont beaucoup écrit, et on sait lire leur écriture et on comprend les différentes langues utilisées. De quoi faire travailler les historien·nes et ce livre raconte certaines de leurs découvertes, en se focalisant sur la vie des gens (vous ne trouverez pas grand'chose sur les monuments).

On ne sait pas tout, bien sûr. Et certains historiens ont comblé les trous avec leur imagination. Comme le note l'auteure, « c'est parfois comme si on essayait de reconstruire l'histoire de la guerre d'Irak uniquement à partir des discours de George Bush ». Ce livre parle aussi de l'histoire de l'histoire, comment notre vision de la Mésopotamie et de ses habitant·es a changé au cours du temps. Et l'introduction explique, au moment où la science est attaquée de toute part, pourquoi l'histoire est importante.

Le livre est très lisible (pas besoin d'être historien·e professionnel·le, ni de parler sumérien ou akkadien) et très vivant. Outre la princesse (et grande prétresse, car on n'avait pas peur du cumul des mandats, à l'époque) Ennigaldi-Nanna, vous suivrez donc le scribe Nabû-shuma-iddin, le roi Shulgi, la tenancière de bistrot Ku-bau (vous verrez qu'elle a connu ensuite une belle ascension sociale), l'astronome Balasî, la malade Beltani, qui consultait les dieux sur sa santé, la poétesse Enheduanna, toutes et tous de vraies personnes qui ont existé, et dont le nom est écrit pour l'éternité sur des tablettes d'argile.

Ah, et puisque l'auteure raconte qu'elle a choisi cette voie professionnelle grâce à Irving Finkel, je vous incite fortement à voir ses géniales vidéos faites au British Museum, notamment dans la série Curator's Corner (ma préférée).

Pour commander le livre, l'auteure propose plusieurs liens.


L'article seul

RFC 9750: The Messaging Layer Security (MLS) Architecture

Date de publication du RFC : Avril 2025
Auteur(s) du RFC : B. Beurdouche (Inria & Mozilla), E. Rescorla (Windy Hill Systems), E. Omara, S. Inguva, A. Duric (Wire)
Pour information
Réalisé dans le cadre du groupe de travail IETF mls
Première rédaction de cet article le 23 avril 2025

On le sait, un des problèmes stratégiques de l'Internet est l'absence d'un protocole de messagerie instantanée standard et largement répandu. Autant le courrier électronique fonctionne relativement bien entre logiciels différents, autant la messagerie instantanée est un monde de jardins clos, incompatibles entre eux, et qui nécessite d'installer vingt applications différentes sur son ordiphone. L'interopérabilité reste un objectif lointain. Il n'y a pas de solution simple à ce problème mais le système MLS (Messaging Layer Security) vise à au moins fournir un mécanisme de sécurité pour les groupes, mécanisme qui peut ensuite être utilisé par un protocole complet, comme XMPP (RFC 6120). MLS est normalisé dans le RFC 9420 et cet autre RFC, le RFC 9750, décrit l'architecture générale.

Les services de sécurité que doit offrir MLS sont les classiques (confidentialité, notamment) et, bien sûr, doivent être assurés de bout en bout (l'opérateur du service ne doit pas pouvoir casser la sécurité et, par exemple, ne doit pas pouvoir lire les messages). Quand il n'y a que deux participants, c'est relativement facile mais MLS est prévu pour des groupes, allant de deux à potentiellement des centaines de milliers de participant·es.

Le protocole, on l'a vu, est spécifié dans le RFC 9420. Il repose sur l'envoi de messages de maintenance du groupe, comme le message Proposal, qui demande un changement dans la composition du groupe, ou Commit, qui va créer une nouvelle epoch, c'est-à-dire un nouvel état du groupe (la ressemblance avec le commit d'un VCS comme git est volontaire). Les clés effectivement utilisées pour le chiffrement sont liées à cet état, et changent avec lui.

Le protocole MLS repose sur deux services, qui doivent être fournis pour qu'il puisse fonctionner (voir aussi la section 7) :

  • Un service d'authentification des utilisateurices, l'AS (Authentication Service, section 4 du RFC), qui permettre d'obtenir les clés publiques, avec la garantie qu'elles sont bien liées à l'identificateur utilisé par l'utilisateurice,
  • Un service de livraison, le DS (Delivery Service, section 5), qui va se charger de porter les messages.

Il n'y a pas besoin de faire confiance au DS, tous les messages étant chiffrés. La seule possibilité d'action d'un DS malveillant serait de ne pas transmettre les messages. (Par contre, un AS malveillant pourrait casser toute la sécurité, en envoyant des clés publiques mensongères, permettant par exemple l'espionnage.)

MLS n'impose pas une forme particulière à l'AS et au DS. Par exemple, il pourrait utiliser une PKI (RFC 5280) traditionnelle comme AS. On l'a dit, MLS n'est pas une solution complète de messagerie instantanée, une telle solution nécessite aussi l'AS, le DS et plein d'autres choses. Parmi les systèmes existants, on peut noter que PGP repose sur les serveurs de clés et le Web of Trust comme AS et sur le courrier comme DS. Signal repose sur un système centralisé comme DS et sur une vérification des clés par les utilisateurices comme AS (voir aussi la section 8.4.3.1 de notre RFC, sur l'authentfication des utilisateurices).

Le RFC rappelle que MLS ne met pas de contrainte à ces messages de changement du groupe. Si on veut le faire (par exemple créer des groupes fermés au public), cela doit être fait dans le protocole complet, qui inclut MLS pour la partie « chiffrement au groupe ». Par contre, MLS impose que tous les membres du groupe connaissent tous les autres membres. Il n'y a pas de possibilité d'avoir des membres cachés (cela serait difficilement compatible avec le chiffrement de bout en bout). Et le DS peut, selon les cas, être capable de trouver ou de déduire la composition d'un groupe (voir section 8.4.3.2).

Mais alors, que fait MLS ? Il gère la composition des groupes et ses changements dans le temps, et le matériel cryptographique associé. Via le DS, tous les membres du groupe génèrent les clés secrètes nécessaires et les messages peuvent être chiffrés pour tout le monde. MLS ne comprend pas le format des messages, il chiffre des octets, sans avoir besoin de connaitre l'application au-dessus.

Ah, et un peu de sécurité (section 8 du RFC). Il est très recommandé de faire tourner MLS sur un transport chiffré, comme QUIC (RFC 9000) ou TCP+TLS (RFC 8446) car, même si certains messages sont chiffrés, des métadonnées ne le sont pas. MLS fonctionne sur l'hypothèse que tout ce qui n'est pas une extrêmité du réseau (une des machines qui communiquent) est un ennemi (RFC 3552).

Autre question de sécurité, les push tokens, qui ont fait parler d'eux lors de discussions sur la sécurité de certaines messageries instantanées. Ils sont utilisés pour la distribution de contenu, par exemple pour prévenir les utilisateurices qu'un nouveau message est arrivé. Sans système de push, les machines clients devraient périodiquement interroger les serveurs, ce dont leurs batteries se plaindraient certainement. Mais les push tokens ont l'inconvénient de pouvoir être liés à des informations permettant d'identifier un·e utilisateurice. Cela ne compromet pas le contenu des messages (qui est chiffré) mais donne accès à des métadonnées bien révélatrices. Et les États utilisent cette possibilité. Le problème est compliqué car il n'y a pas de solution de remplacement, à part l'attente active. C'est ainsi que Proton a noté : « That said, we will continue to use Apple and Google push notifications when the services are available on the device because unfortunately they are favored heavily by the operating system in terms of performance and battery life. »  Mais Tuta a fait un autre choix. Notre RFC suggère quelques pistes comme l'introduction de délais aléatoires.

La section 8 donne beaucoup d'autres conseils de sécurité et sa lecture est recommandée. Notez par exemple que le protocole MLS du RFC 9420 a fait l'objet de plusieurs analyses de sécurité (la liste figure dans la section 8.6).

Il existe un site Web du projet MLS mais il a très peu de contenu. Question mises en œuvre de MLS, une liste est disponible, citant, par exemple, la bibliothèque BouncyCastle ou bien OpenMLS (avec une documentation très complète).

Téléchargez le RFC 9750


L'article seul

Un million de routes

Première rédaction de cet article le 17 avril 2025

Si vous suivez l'actualité du routage sur l'Internet, vous avez peut-être vu des messages comme quoi on atteindrait bientôt « un million de routes ». Mais ça veut dire quoi et, surtout, est-ce que ce chiffre a un sens ?

Un exemple d'un tel message est ce tweet. Le graphique qu'il référence indique qu'on est proche de 999 000 routes. Si vous utilisez le service bgp.bortzmeyer.org, vous verrez par contre qu'on a déjà dépassé le million (1 031 455 aujourd'hui). L'un des deux a-t-il tort ? Non.

Le fond de l'affaire est que le routage Internet est décentralisé. Revenons à comment ça fonctionne. Les routeurs du cœur de l'Internet (ce qui correspond à peu près à la zone sans route par défaut) annoncent à leurs pairs (en utilisant le protocole BGP) les préfixes d'adresses IP qu'ils savent joindre (un préfixe = une route). Ces pairs retransmettent ensuite à leurs propres pairs une partie des annonces reçues, selon leur politique. Parfois, ils agrègent plusieurs préfixes en un seul, plus général. Parfois, ils décident de ne pas transmettre des routes, par exemple parce qu'elles sont trop générales ou trop spécifiques. Résultat, chaque routeur voit une table de routage légèrement différente, plus ou moins grande.

Notez aussi que le chiffre cité dans le tweet plus haut est celui pour IPv4. Il y a beaucoup plus de routes IPv4 qu'IPv6 en raison du découpage de plus en plus fin des préfixes, pour gérer la pénurie d'adresses IPv4. IPv6, où l'agrégation est bien meilleure, a moins de préfixes annoncés. Au passage, si vous êtes soucieux de l'empreinte environnementale du numérique, notez qu'IPv6 impose donc une charge moins forte aux routeurs, et devrait donc logiquement être déployé partout. Un graphique d'IPv4 : bgp-soon-million.png

Le service bgp.bortzmeyer.org utilise le RIS, un système comprenant de nombreux routeurs, bien connectés. Il sert pour l'étude et l'analyse. Il voit donc davantage de routes qu'un routeur « de production ». (RouteViews a aujourd'hui 1 035 346 routes.) Mais même ces routeurs « de production » ne voient pas tous la même chose, en fonction de leurs pairs et de leur politique de filtrage. On ne pourra donc pas faire un feu d'artifice pile au moment où l'Internet IPv4 atteindra le million de routes.


L'article seul

RFC 9726: Operational Considerations for Use of DNS in Internet of Things (IoT) Devices

Date de publication du RFC : Mars 2025
Auteur(s) du RFC : M. Richardson (Sandelman Software Works), W. Pan (Huawei Technologies)
Réalisé dans le cadre du groupe de travail IETF opsawg
Première rédaction de cet article le 1 avril 2025

Les objets connectés, vous le savez, sont une source d'ennuis et de risques de sécurité sans fin. Non seulement ils ne sont pas forcément utiles (faut-il vraiment connecter une brosse à dents au réseau ?) mais en outre, comme ils incluent un ordinateur complet, ils peuvent faire des choses auxquelles l'acheteur ne s'attend pas. Pour limiter un peu les risques, le RFC 8520 normalisait MUD (Manufacturer Usage Description), un mécanisme pour que le fournisseur du machin connecté documente sous un format analysable les accès au réseau dont l'objet avait besoin ce qui permet, par exemple, de configurer automatiquement un pare-feu, qui va s'assurer que la brosse à dents ne se connecte pas à Pornhub. Dans un fichier MUD, les services avec lesquels l'objet communique sont typiquement indiqués par un nom de domaine. Mais le DNS a quelques subtilités qui font que l'utilisation de ces noms nécessite quelques précautions, décrites dans ce nouveau RFC.

En fait, le RFC 8520 permet d'utiliser des noms ou bien des adresses IP, qui seront ensuite ajoutées dans les ACL du pare-feu. Évidemment, les noms de domaine, c'est mieux. Pas pour la raison qu'on trouve dans tous les articles des médias « les noms de domaine sont plus simples à retenir pour les humains » puisque les fichiers MUD ne sont pas prévus pour être traités par des humains. Mais parce qu'ils sont stables (contrairement aux adresses IP, qui changent quand on change d'hébergeur), qu'ils gèrent à la fois IPv4 et IPv6 et parce qu'ils permettent la répartition de charge, par exemple via un CDN.

Mais le pare-feu (sauf s'il espionne la résolution DNS préalable) ne voit pas les noms de domaine, il voit des paquets IP, avec des adresses IP source et destination. (Ainsi que les ports, si le paquet n'est pas chiffré.) Il va donc falloir résoudre les noms en adresses si on veut configurer le pare-feu à partir du fichier MUD, et c'est là que les ennuis commencent. Les exigences de sécurité sont contradictoires (section 9 du RFC) : on veut bloquer les accès au réseau mais « en même temps » les permettre. Cette permission est nécessaire pour que l'objet connecté puisse mettre à jour son logiciel, par exemple lorsqu'une faille de sécurité est découverte. Et c'est également nécessaire pour que le vendeur de l'objet puisse recevoir des quantités de données personnelles, qu'il revendra (ou se fera voler suite à un piratage).

Le plus simple (section 3 du RFC) pour traduire les noms de domaine du fichier MUD en adresses IP est évidemment que le contrôleur MUD, la machine qui lit les fichiers MUD et les traduit en instructions pour le pare-feu (RFC 8520, sections 1.3 et 1.6) fasse une résolution DNS normale et utilise le résultat. C'est simple et direct. Mais notre section 3 décrit aussi pourquoi ça risque de ne pas donner le résultat attendu. Par exemple, le résolveur DNS peut renvoyer les résultats (les différentes adresses IP) dans un ordre variable, voire aléatoire, comme décrit dans le RFC 1794. C'est souvent utilisé pour faire une forme grossière de répartition de charge. Si le résolveur renvoie toutes les adresses IP possibles, OK, le contrôleur MUD les autorise toutes dans le pare-feu. Mais s'il n'en renvoie qu'une partie, on est mal, celle(s) autorisée(s) ne sera pas forcément celle(s) utilisée(s) par l'objet connecté. Et la résolution peut dépendre du client (le RFC parle de « non-déterminisme » ; en fait, c'est parfaitement déterministe mais ça dépend du client, par exemple de sa géolocalisation). Si le serveur faisant autorité renvoie une seule adresse qui dépend de la localisation physique supposée de son client, et que le machin connecté et le contrôleur MUD n'utilisent pas le même résolveur DNS, des ennuis sont à prévoir : l'adresse autorisée sur le pare-feu ne sera pas celle réellement utilisée.

Si contrôleur et truc connecté utilisent le même résolveur, le risque d'incohérence est plus faible. Les réponses seront les mêmes pour les deux (contrôleur et chose connectée). Cela peut être le cas dans un environnement résidentiel où tout le monde passe par le CPE (la box) qui fait à la fois résolveur DNS, routeur NAT et pare-feu. Mais que faire si, par exemple, la brosse à dents ou l'aspirateur connecté utilisent un résolveur DNS public, quelque part dans le mythique nuage ?

La section 4 du RFC liste tout ce qu'il ne faudrait pas faire en matière d'utilisation du DNS par les objets connectés. Typiquement, l'objet connecté utilise HTTPS pour se connecter à son maitre (le vendeur de l'objet ; le gogo qui a acheté l'objet connecté croit en être propriétaire mais il dépend du vendeur, qui peut arrêter le service à tout moment). Pour le cas d'une mise à jour logicielle, le maitre informe alors si une mise à jour du logiciel est nécessaire, en indiquant l'URL où l'objet va pouvoir récupérer cette mise à jour. Évidemment, il est préférable pour la sécurité que cette mise à jour soit signée (RFC 9019). Notez que ce qui est bon pour la sécurité face au risque de piratage par un tiers n'est pas forcément bon pour le consommateur : la vérification de la signature va empêcher les utilisateurs de mettre leur propre logiciel par exemple parce que le vendeur ne fournit plus de mise à jour.

Questions bonnes pratiques, d'abord, il faut utiliser le DNS, donc un nom de domaine dans l'URL, pas des adresses IP littérales. Cette approche aurait certes l'avantage de fonctionner même quand la résolution DNS est défaillante, mais elle souffre des problèmes suivants :

  • Il faut choisir entre une adresse IPv4 et IPv6, alors que le maitre ne sait pas forcément de quelle connectivité dispose l'objet. Si l'objet se connecte en IPv4 au maitre, celui-ci pourrait croire qu'une adresse IPv4 littérale est acceptable ce qui n'est pas vrai si l'objet est connecté via NAT64 (RFC 6146). Dans cet exemple, le DNS marcherait (RFC 6147) mais pas l'adresse littérale.
  • Ensuite, l'adresse IP peut changer fréquemment, par exemple si le vendeur change d'hébergeur. C'est justement le principal avantage du DNS que de permettre une stabilité des identificateurs sur le long terme et non pas, comme on le lit souvent parce que « les noms sont plus lisibles et plus mémorisables que les adresses », argument qui ne s'applique pas aux objets connectés.
  • Enfin, si la mise à jour est récupérée via HTTPS, ce qui est évidemment recommandé, le serveur doit obtenir un certificat et peu d'AC acceptent d'émettre des certificats pour des adresses IP (à l'heure de la publication de ce RFC, Let's Encrypt a annoncé qu'ils allaient le permettre mais cela ne semble pas encore fait).

Autre problème, des noms de domaine qui, en raison des systèmes utilisés sur le service HTTP, par exemple un CDN, changent souvent et de manière qui semble non déterministe. Modifier les fichiers MUD ne sera alors pas possible. Le RFC recommande, s'il faut absolument changer les noms souvent, de mettre un alias dans le fichier MUD, modifié à chaque fois que le nom change.

Toujours du côté des CDN, même s'ils ne sont pas les seuls à poser ce genre de problème, les noms trop génériques. Si tous les clients du service d'hébergement sont derrière le même nom de domaine, celui-ci sera difficile à modifier, et les effets d'une compromission pourront être plus étendus que souhaitable. Il vaut mieux des noms spécifiques à chaque client.

Les requêtes faites par le contrôleur MUD peuvent poser des problèmes de confidentialité (section 5 du RFC). Si le résolveur local n'est pas jugé digne de confiance, et que le contrôleur MUD utilise un résolveur distant, par exemple un résolveur public comme ceux de Cloudflare ou Quad9 (de préférence avec chiffrement, via DoH RFC 8484, DoT RFC 7858 ou DoQ RFC 9250), il faut s'assurer que l'objet va utiliser ce même résolveur (il n'y a pas aujourd'hui de mécanisme dans MUD pour faire cela automatiquement).

Les recommandations positives, maintenant (section 6). Le fichier MUD peut être obtenu de diverses façons (par exemple via un code QR comme documenté dans le RFC 9238), c'est son contenu qui compte. Les conseils de la section 6 sont en général du simple bon sens, qui correspondent aux bonnes pratiques habituelles d'utilisation des URL, mais qui ne sont pas toujours appliquées par les objets connectés. Notre RFC recommande :

  • D'utiliser le DNS (et pas des adresses IP littérales comme le font trop de vendeurs),
  • d'utiliser des noms contrôlés par le vendeur de l'objet (et pas par son hébergeur Web), éventuellement en utilisant des alias (RFC 9499, section 2),
  • d'utiliser des CDN dont les serveurs faisant autorité retournent plusieurs réponses, quitte à les réordonnancer pour la répartition de charge, pour augmenter la probabilité que le contrôleur MUD et l'objet aient des adresses en commun,
  • de ne pas utiliser des réponses adaptées au client DNS ; un mécanisme comme ECS (RFC 7871) permet de donner des réponses différentes selon l'adresse IP du client final (et pas celle du client que voit le serveur faisant autorité), ce qui va créer des problèmes si le contrôleur MUD et l'objet passent par des connexions Internet différentes,
  • d'utiliser le résolveur local (celui indiqué via DHCP ou RA - RFC 8106), en s'appuyant sur les techniques décrites dans les RFC 9462 et RFC 9463 ; l'utilisation de résolveurs DNS publics est découragée, à mon avis pour de mauvaises raisons.

Notez que l'objet peut aussi utiliser des noms mais ne pas se servir du DNS pour les traduire en adresses IP. C'est le cas par exemple s'il utilise mDNS (RFC 6762 et RFC 8882) qui, en dépit de son nom, n'est pas du DNS, ce qui peut également poser des problèmes d'incohérence (l'objet n'obtenant pas la même adresse IP que le contrôleur MUD).

La section 8 revient sur les questions de vie privée (RFC 7626). Elle dit (ce qui est peut-être contestable) que les requêtes DNS d'un four à micro-ondes ne sont pas forcément un enjeu d'intimité mais que celles d'un sextoy le sont davantage. L'utilisation de DoT ou DoH va supprimer le risque d'une écoute par un tiers mais le résolveur, dans tous les cas, voit la requête et il faut donc choisir un résolveur de confiance, sauf à utiliser des techniques qui sont pour l'instant très rares, comme celle du RFC 9230. Ah, et le RFC discute aussi des risques posés par la divulgation de la version de logiciel actuellement utilisée par l'objet (qui va lui servir à savoir s'il faut une mise à jour) mais le RFC 9019 a déjà traité cela.

Téléchargez le RFC 9726


L'article seul

Association entre adresse IP et AS

Première rédaction de cet article le 29 mars 2025

Dans les discussions au sujet du réseau Internet, on voit souvent passer des demandes sur l'AS associé à une adresse IP ou bien le contraire. Mais les questions simples du genre « de quel AS dépend une adresse IP ? » sont… trop simples.

Il n'y a en effet pas d'association simple : une adresse IP peut être annoncée via BGP par plusieurs AS (même si ce n'est pas le cas le plus courant) et, surtout, surtout, il faut différencier l'association administrative (quel opérateur s'est fait allouer quelle adresse IP) et l'association technique (que voit-on avec BGP).

Commençons par la partie administrative. Un opérateur réseau est typiquement LIR, membre d'un RIR, un registre d'adresses IP, dont il obtient des adresses IP (ou plus exactement des préfixes regroupant de nombreuses adresses). On peut obtenir l'information sur ces allocations de préfixe avec des protocoles comme whois ou RDAP (comme pour les noms de domaine) ou simplement via le site Web du registre. whois est très ancien, a plusieurs limites sérieuses (pas de jeu de caractères normalisé, zéro sécurité, il n'est même pas chiffré, etc). RDAP convient mieux pour programmer. Ici, comme je suis vieux et conservateur, je vais utiliser whois, d'autant plus que, dans certains RIR, de l'information sur l'AS d'origine est distribuée en whois mais pas en RDAP (qui n'a pas de réponse normalisée pour cette information). Je me demande quel opérateur a obtenu l'adresse 18.220.219.93 (choisie car elle héberge un ramasseur d'une boite d'IA, qui vient de passer sur ce blog). 

% whois 18.220.219.93
…
NetRange:       18.32.0.0 - 18.255.255.255
CIDR:           18.128.0.0/9, 18.64.0.0/10, 18.32.0.0/11
Organization:   Amazon Technologies Inc. (AT-88-Z)
…

OK, c'est une machine d'AWS. Je connais donc l'opérateur. La base de l'ARIN ne stockait apparemment pas le numéro d'AS de AWS. Celle du RIPE-NCC est en général de meilleure qualité donc on va réessayer avec une adresse européenne (un autre visiteur de ce blog, un ramasseur pour un moteur de recherche). 

% whois 91.242.162.6
…
inetnum:        91.242.162.0 - 91.242.162.255
netname:        QWANT-NET
org-name:       QWANT SAS
…
route:          91.242.162.0/24
descr:          QWANT SAS
origin:         AS199064

Cette fois, dans l'objet de type route (qui, comme indiqué plus haut, n'est pas encore disponible pour RDAP), on a le numéro de l'AS associé à cette adresse. On peut obtenir des informations sur cet AS via whois (whois AS199064…), RDAP, etc. Cette information peut être utilisée pour bâtir automatiquement des règles de filtrage pour les routeurs BGP (on utilise alors la base du RIR comme IRR, Internet Routing Registry) en considérant que seul cet AS peut annoncer ce préfixe 91.242.162.0/24. Un exemple d'IRR public, qui agrège les informations des RIR et en ajoute certaines, est celui de NTT. Rappelez-vous que toutes ces bases de données sont de qualité… variable.

Mais tout ceci, c'est purement administratif. Ce sont des bases de données relativement statiques qui sont stockées par les RIR. Dans l'Internet vivant et dynamique, c'est autre chose. Là, il faut regarder ce que contiennent les tables BGP, remplies par ce protocole de routage. Là, ce sera bien plus dynamique (mais pas plus « réel »). On peut consulter ces tables si on gère un routeur BGP situé dans la DFZ mais, comme ce n'est probablement pas le cas de la majorité des lecteurices de ce blog, on va utiliser les outils disponibles en ligne. Servons-nous par exemple du service en bgp.bortzmeyer.org. 

% curl -s https://bgp.bortzmeyer.org/18.220.219.93
18.220.0.0/14 16509

L'adresse IP allouée à Amazon est annoncée en BGP par l'AS 16509. C'est l'AS d'Amazon, ce qui ne nous surprendra pas mais, bien sûr, un préfixe peut être annoncé par un autre opérateur que celui qui l'a réservé. Regardez par exemple 2001:678:4c::1, réservé par l'Afnic, mais annoncé en BGP par son hébergeur, PCH (dont le numéro d'AS, que je vous laisse trouver, donne une bonne idée de la culture et de l'ancienneté de cette organisation).

Ah, et j'avais dit qu'une adresse IP pouvait être annoncée par plusieurs AS. C'est surtout le cas pour les services anycastés. Regardez avec le script bgproute (présenté dans la page citée plus haut). 

% bgproute 2001:678:c::1      
2001:678:c::/48 2486 2484

% bgproute  2001:503:d2d::30
2001:503:d2d::/48 36617 21313 40647 396599 397196 396566 396576 19836 397193 396555 396550

Le premier est annoncé par deux AS, le deuxième par pas moins de onze AS différents.

J'insiste sur le fait que les deux visions, l'administrative dans les bases des RIR, et la technique dans les tables BGP, sont aussi « authentiques » ou « correctes » l'une que l'autre. Ce sont simplement deux visions différentes de l'objet socio-technique assez complexe qu'est l'Internet.


L'article seul

DNS hackathon 2025 in Stockholm

First publication of this article on 23 March 2025

On 15 and 16 March 2025, I was at the DNS hackathon 2025 in Stockholm, organised by RIPE NCC, DNS-OARC and Netnod. I worked on a mechanism to synchronize the caches of DNS resolvers.

Hackathons are meant to be a collective work. After all, if you just code alone, you can as well stay at home/office. The organisers insist that you make big groups, with people of various profiles. (Speaking of diversity, there was apparently two women for more than thirty participants, which is typical for hackathons.) The subject I championed, implementation and interoperability of DELEG, did not raise sufficient interest so I went to another project, Poisonlicious. The idea for this project came from Quad9, a big public DNS resolver. Their network of resolvers is made of many sites, each with several physical machines, each physical machines hosting several virtual machines. When a DNS client asks the resolution of a domain name, each of the virtual machines has to do it on its own, without sharing work with the others, even if they were very close. The idea is therefore to synchronize the caches: when a machine finishes the resolution work, it sends a copy of the responses it got to other machines.

The practical work included:

  • Patching the Unbound resolver to be able to both send and receive these data,
  • Writing an Internet draft to document the idea, and the work to do (I worked mostly on this task).

In the current iteration of the Internet-Draft, the data is sent as an ordinary DNS message in UDP, authenticated by TSIG (otherwise, poisoning other machines with bad data is a risk). In the future, techniques like MQTT may be used for efficient synchronization.

The work done by Willem Toorop on Unbound is in this pull request (it required to add TSIG support in Unbound, which did not need it before). The Internet draft is draft-bortzmeyer-dnsop-poisonlicious. It will be discussed in the dnsop IETF working group. I also developed a small program in Python, using the excellent dnspython library to resolve a domain name and send it, following the protocol, to the receiving machine: poisonlicious.py. Reading its source code gives you a good idea about how the mechanism works. You can also get a pcap of the packet sent: poisonlicious.pcap (the command was python poisonlicious.py www.afnic.fr). But nothing extraordinary, it is an ordinary DNS packet, with the TSIG signature.

There were other interesting projects during this hackathon:

  • resviz (DNS resolution visualizer). The goal is to be pedagogical (how resolvers work by showing the authoritative servers queried).
  • Babies (from the Stork project, I let you find the reason for the name Babies). Monitoring / controlling multiple DNS servers from different vendors by proxying to their different APIs. NSD proved to be a bit tough during the hackathon. This project published its own report in a detailed article.
  • LHB ("Lookup Hostname Best practices") addressed the problem with getaddrinfo. Basically, the function getaddrinfo is available everywhere but very limited (no other types than the IP addresses, no information about whether the resolution was validated, for instance with DNSSEC, etc). Daniel Stenberg was not at the hackathon but was often quoted since he wrote a lot about getaddrinfo issues. Also, there was a great talk at the last FOSDEM on this: "getaddrinfo sucks, everything else is much worse". The hackathon project added some code in Ladybird.
  • Canned DNS was about breaking the DNS on purpose, in order to exercise testing tools like Zonemaster. They created a DNS server giving bad answers (two SOA, discrepancy between section count and the actual section, NXDOMAIN with data, etc). Unlike IBDNS, it will be specific to a test program. It is written in Go (not everyone subscribed yet to the Rust cult). I specially appreciated the fact that responses are not hardwired in the code but configured in TOML, which allows you to configure responses at will. Also, this project got the prize "most complete project".
  • idIOT: DNS for Internet of stuff that spies on you. Current implementations of DNS on things are often broken. They do not respect TTL, they hardwired resolver IP addresses, etc. idIOT documented that. This hackathon project got the prize for "best project name".
  • DohoT or Donion. An ordinary resolver knows both the IP address of its client and the question asked, which is bad for privacy. The idea is to add an intermediary (client → proxy → resolver, with encryption), the intermediary will know the client address but not the question and the resolver will only know the question. If they don't collude, it is safe. Tor is cool but too slow (long circuits, may be with high latency, which is really bad for the DNS). Oblivious DNS (RFC 9230) may be the solution but is a new protocol. Six solutions were tested during the hackathon, ordinary DoH is the fastest (of course), improved Tor with shorter directed circuits may be the best solution.

Thanks to Vesna Manojlović who convinced me to come, to Johanna Eriksson and Denesh Bhabuta for the organisation, and to my nice project group, Willem Toorop, Babak Farrokhi and Moin Rahman.


L'article seul

Articles des différentes années : 2025  2024  2023  2022  2021  2020  2019  Précédentes années

Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.

Un article de ce blog au hasard.